On 2020-11-14, avv. Nicola Dell'Uomo <[email protected]> wrote: > > Hi, > > thank you for answering. > > I raised class limit to 4096 current and 8192 max, but nothing changes: > the logs report exactly the same error scheme as before. > > Do you use this client?
No, but the error messages are pretty clear, and I can see that it uses kqueue for file monitoring (via libinotify which emulates Linux's inotify interface using kqueue) so it's a fairly safe bet that's what you're running into. Did you re-login after cbanging login.conf? Check the new values show up with ulimit. > Does it work for you? > > I have many files in each directory, but it works out of the box with > other OS, so I was trying to understand why this is happening in OpenBSD. OpenBSD has pretty tight default limits, plus kqueue works differently than the native inotify on Linux causing it to use more file descriptors. (All dirs and files, not just dirs). > puffy$ ulimit -s > 4096 -s is stack. You want -n (or -a to show all values). > puffy$ sysctl kern.nfiles > kern.nfiles=708 > > I do agree kern.maxfiles is wildly high: this limit was obviously not > meant for production but just for testing purposes... It's not uncommon to set things "for testing" and forget that they're there until the system falls over badly. > Moreover I can't figure out why first sync works and all files are > regularly saved to local destination; then it stops saving to local, but > I can still use all other client function... I suppose if it just syncs all files then it doesn't need to monitor them for updates. >
