On 2024/09/06 09:44, Dylan D'Silva wrote: > > > > > > > > > > > > > > > > I run aerc from a staff account. Therefore I updated my > > > > > > > > /etc/login.conf > > > > > > > > under staff to increase the openfile-cur size to 71600 and > > > > > > > > openfile-max > > > > > > > > to 72000 > > > > > > > > :openfiles-cur=71600:\ > > > > > > > > :openfiles-max=72000:\ > > > > > > > > > > > > > > If you're going to do this, I would recommend a "normal" > > > > > > > openfiles-cur, > > > > > > > just raise openfiles-max. Then start such software from a script > > > > > > > or > > > > > > > shell alias which uses ulimit -n to raise the limit just for that > > > > > > > software. > > > > > > What do you consider normal? In your comment below, you made comment > > > about not many people running computers from the 80's. > > > > I think Stuart meant that you could leave openfiles-cur with it's > > default value (in case you hadn't changed it before for something else) > > and only increase openfiles-max to your desired value. Then you can > > start aerc from a script like the following: > I understood what Stuart meant in regards to the cur-max comment. You > missed the point I was making. Stuart thinks its pointless to use > cap_mkdb as modern systems are fast enough to handle larger login.conf > files. Yet Stuart thinks an openfile-cur of 128 is sufficient. So I
I don't think that openfiles-cur=128 is sufficient in most cases. 128 is the default for the "daemon" login class, but other classes are higher, and daemons expecting to use more than this in normal use either do the equivalent of ulimit -n to raise to openfiles-max (default 1024 for daemon at least on the archs I checked) or have separate login.conf classes. I even think the current default limits may be a little low for standard use on average machines of some arch, but there's a wide range of hardware supported by say OpenBSD/amd64, some much smaller than others, and we'd need to first talk about raising kernel limits because the current login.conf defaults (openfiles-cur=512, openfiles-max=1024) are I think appropriate for the default kern.maxfiles. > asked what is his definition of normal. I then pointed to the inotify > change of 2020 in Linux kernel which set a range of 8192 to 104576. Does > he have a standard or something to reference or is this just opinion? Limit ranges in the Linux kernel don't really have anything to do with what's done in OpenBSD. > > #!/bin/sh > > > > ulimit -n 72000 > > aerc > How does that solve the mentioned problem of people running multiple > aerc instances? It doesn't, but it does provide bounds to at least stop other out of control processes consuming large amounts of kernel memory and limits it to just aerc. > > > It's worth mentioning but the syncthing pkg-readme suggest a openfile of > > > 4096. If this with aerc was talking about 4096 then I'd be more inclined to document it in the readme like we do with syncthing. But the sizes needed for some mailboxes at one open FD per email are pretty huge and the proposed 72000 is so far above the default whole-system limit that it seems irresponsible to recommend, at least without analysis from someone who has a better handle on the kernel impact of this. (Also if doing that, someone else later may say "oh but aerc's pkg-readme says 72000 is ok, so why can't we have 100000?") > > > > > > > We are mostly not running on computer systems from the 80s and > > > > > > > the file > > > > > > > is not really slow to parse - however having the db files around > > > > > > > does > > > > > > > cause trouble when someone forgets to rerun cap_mkdb after > > > > > > > changing the > > > > > > > file later. I would not recommend this. > > > > > > The man page for login(5).conf has that comment. Along with a note "Using a database version for small files does not result in a performance improvement" and a reminder that it be re-run after every change to the file. Also it is a bit more buried there and less likely to be seen by not-so-technical users than the pkg-readme instructions. > > > How about improving Kqueue to support recursive watching? I think it may still need the watches on individual files if you want to detect when they are changed - so while it might help in some ways, I'm not sure it would actually lower the FD requirements.
