On 9 Jun 2017, at 5.03, M. Balridge <dove...@r.paypc.com> wrote: > 1) In src/lib/compat.h there is a definition for p(read|write) that conflicts > with the one in /usr/include/unistd.h > > On this box, there is a macro appended to the definition (to control whether > or not THROW is defined in C++ "mode"). This is regulated by using the macro > __THROW. I assume this is anachronistic.
I don't know about this. Anyway, can't apply this patch since it likely fails elsewhere. > 2) There was an odd overflow bug in the quota module. (Yes, would you believe > that user quotas are used + enforced on this Frankenbox?) I assume it's a > rarely seen issue because few Dovecot users compile the software in caves on > computers powered by horse-pulled generator wheels. I suspect Timo's seen > more Abominable Snowcreatures in Espoo than systems like these. > > Simply adding an explicit 64 bit (unsigned) type to the constant multipliers > seemed to address this. Of these two patches, this is probably the most "safe" > and thus likely to be accepted into the main branch of code. Yeah, I'll add that one. Not really sure if that's a generic 32bit problem. Nobody has previously complained about it though. > Thanks for the great software, as always, Timo. It's a testimony to your > design and implementation acumen that software you've written in 2017 still > runs on machines that went obsolete in 480 B.C.E. For a long time Dovecot supported C89 compilers, but nowadays we at least require proper C99 compilers.. > I am trying to track down one possible issue that could be locking-related, > which causes some mailbox open operations to see to take longer than they > should. Log entries like: > >> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log >> was locked for 95 seconds (rotating while syncing) > >> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log >> was locked for 92 seconds (rotating while syncing) As Joseph mentioned, this is likely happening because Dovecot is doing a lot of work while keeping the log file locked. The "rotating while syncing" is probably not the real reason. I think it's just doing a lot of work on the mbox file itself (reading/writing/rewriting). Would be nice of course if it logged more information, but mbox format is a bit too legacy to spend much time on improving. > imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock, > group=501(coregroup)) failed: Operation not permitted (egid=200(users), group > based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm) > > imap(luser): Error: file_dotlock_open() failed with subscription file > /home/luser/mail/.subscriptions: Operation not permitted > > .subscriptions doesn't exist either as a file or a directory in the named > directories. Client is trying to subscribe, and Dovecot wants to create subscriptions file. Dovecot wants to preserve the group permissions from the /home/luser/mail directory, but it has no permission to set the file's group to "users", so it aborts. You could chmod 0700 /home/luser/mail if possible. > Is there a "filter" against dot-files being opened within the bowels of > dovecot? The problem above isn't dotlock, but rather the file permission preservation in general.
