From: Stuart Henderson Subject: Re: [revision] mail/aerc: include pkg/README? To: Johannes Thyssen Tishman Cc: ports@openbsd.org, Dylan D'silva Date: Thu, 5 Sep 2024 13:09:51 +0100 On 2024/09/05 12:52, Johannes Thyssen Tishman wrote: > The email below was sent to the aerc-discuss mailing list a couple of > days ago. Is it worth adding a pkg/README for this? > > 2024-09-03T23:12:23Z "Dylan D'silva" : > Hello all, > > After some digging I've come to a solution. For those on a BSD system > with large MAILDIR, you'll require something similar. Aerc uses > github.com/fsnotify/fsnotify to monitor changes to files. BSD system > rely on Kqueue which doesn't support recursive watching of files. ^^ directories > Therefore you require one file descriptor for each file. This does not seem to be a good approach for monitoring emails in Maildirs on kqueue systems. Most of the common changes to a Maildir result in either a new file, rename, or deletion and not actually changes to the contents of the files. AFAIK new files won't show up without rescanning the whole directory - for renamed files I don't think you can find the new name so again you need to rescan - it seems like really it's just going to need an efficient way to pick up changes in the dir. (I suppose this is not going to work well with NFS either which is not an uncommon place to store Maildirs..) > Assuming you are running aerc from the current account. You can > change the limit to match your maildir size. > > For me, I store my maildir in ~/Mail > find . -type f | wc -l #counts number of files > 71514 > > 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. I think it would generally be better to run aerc pointed at an IMAP server though (obviously the IMAP server can just run on the machine running aerc if wanted). > If you use a large login.conf you might want create a database version > with cap_mkdb /etc/login.conf see login.conf(5). 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.