Loading .stignore: too many open files

Support
1

Hello, anybody knows, why the second message is poping up on my mac?

It was with earlier versions than 0.11.17 of syncthing too, because I recognized it some times after an update of syncthing. Atm, I cannot see/reproduce it, so no logs. sorry.

what does it mean?

screenshot.png1166×220 72.1 KB

2

I bet it only happens when you move/download a lot of files.

3

Thanks for the link, that’s correct!

Atm, the logfile is running crazy on the mac. The last weeks, I started to add a folder with about 136,4 GB and 381779 files.

Does it mean, the .stignore files is being ignored and/or not processed?

Thats my output:

sysctl -A | grep kern.maxfiles
Use pstat to view kern.vnode information
Use ps to view kern.proc information
Use pstat to view kern.file information
kernel is not compiled for profiling
kern.maxpartitions: no such MIB
kern.kdebug: value is not available
kern.update: no such MIB
kern.osreldate: no such MIB
kern.ntp_pll: no such MIB
kern.bootfile: no such MIB
kern.dumpdev: no such MIB
kern.ipc: no such MIB
kern.dummy: no such MIB
kern.dummy: no such MIB
kern.logsigexit: no such MIB
kern.symfile: Input/output error
kern.procargs: Invalid argument
kern.dummy: no such MIB
kern.dummy: no such MIB
kern.sysv: no such MIB
kern.dummy: no such MIB
kern.dummy: no such MIB
kern.procargs2: Invalid argument
kern.proc_low_pri_io: no such MIB
kern.low_pri_window: no such MIB
kern.low_pri_delay: no such MIB
kern.posix: no such MIB
kern.tfp: no such MIB
kern.threadsigaltstack: no such MIB
kern.lctx: no such MIB
kern.tty: no such MIB
kern.check_openevt: Invalid argument
vm.vmmeter: no such MIB
vm.dummy: no such MIB
hw.disknames: no such MIB
hw.diskstats: no such MIB
hw.floatingpoint: no such MIB
hw.machinearch: no such MIB
kern.maxfiles = 12288
kern.maxfilesperproc = 10240
kern.maxfiles: 12288
kern.maxfilesperproc: 10240

I will not change anything here, because the system is running and I’ve learned to never change a running system ; - )

4

Well I suggest you add files in smaller batches. I am not sure what exactly happens, as we usually scan files in small portions, but somehow we manage to exhaust the kernel limit.

I think when that happens, we just use the old ignores, and not reload them.

5

I understand, the .stignore files are loaded at the start of syncthing, when “everything is normal” and then they are being used, even when they cannot be reloaded. thats fine. now I can see, that a lot if .stignore files are having trouble being loaded.

ScreenClip.png1192×290 42.3 KB

I cannot (out of lazyness and as a matter of principle) add this folder in smaller batches, because then it’ll be too much work. Its the whole folder, or nothing. otherwise (out of my ignorant user view) I need to experiment with sizes and structures and folders and limits and whatsoever and this is something, the computer should do IMHO.

But if I can help you in any other way, just tell me.

6

Well, I guess the next best thing you can do is write down steps of reproduction and raise a github issue, together with output of sysctl. I cannot really understand why this is happening, so a 100% reproducible case would be nice.

7