Hi Stuart,
thank you for your help!
Now it works (almost).
The matter here was that login.conf limits were not high enough.
With my server configuration seafile client opens ~ 43000 files: I
really didn't expect such an high limit, so I set it to 8192 in login.conf.
Now it works, but it definitely wastes an exaggerate amount of resources.
When I close seafile client, kern.nfiles count drops from ~ 44.000 to ~ 890!
Moreover seafile client consumes a huge amount of cpu time.
I'll monitor the app to see if it's just a momentary situation and if it
can be fine tuned...
I also have problems in making it understand I use a private ca.
When I have news, I'll post them.
If somebody has been using seafile client since longtime and already has
experience, please join in!
Nicola
> On 2020-11-14, avv. Nicola Dell'Uomo
<nicola.dellu...@delluomo-morettin.com> 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.
