So, here is what I discovered so far.
1. private ca: apparently everything works fine if you append your
private ca to /etc/ssl/cert.pem. If somebody has an alternative which
does not involve modifying stock cert.pem, please let me know;
2. seafile client syncs files only if auto update is disabled. You still
have to manually update each single library, but in this case everything
works fine and file count from sysctl kern.nfiles won't go wild.
3. If you enable auto update, file count suddendly passes from ~800 -
2000 to ~45000; the client then uses a huge amount of cpu time and files
don't sync (maybe because there are too many opened files and the system
is not efficient?);
4. if I restrict /etc/login.conf openfiles param to lower numbers (i.e.
~8192), the client just won't work, reporting the same errors as in my
first post (Too many open files);
5. I let the client sync for ~ half an hour and nothing changed: so I
think this unlikely would change in more sync time.
6. on other OS (mac OS and Linux) file count never exceed 3600.
Do you think this could be due to a bug?
As I told you I've been having this problem since 6.6 and on different
(client) hosts, but I never try to figure it out before because I didn't
need seafile to sync my files at the time...
Please let me know if I can help with some tests or data.
Nicola
Il 15/11/20 12:27, avv. Nicola Dell'Uomo ha scritto:
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.
>
