Quoting Joseph Tam :
> If this is output on the dovecot server itself so there's no mismatch
> in pathnames. Have you checked whether the dovecot user can traverse
> all the way from / to /u2/usermail/luser/
The dovecot user, as in the "dummy" user dovecot uses for
I've tried changing how I symbolically linked the mailboxes, i.e.,
creating a sub-directory that is symlinked into the user's mail/
directory versus symbolically linking the mbox files themselves, etc.
No dice. Permissions are fine. I've even resorted to changing the
index locking strategy,
I've gone through and recompiled sendmail (enabling HASFLOCK) and procmail
(disabling lockf()) to harmonise the locking strategies, as it seems various
authors of email software over the years have pontificated with great force
and wind about which locking strategy was truly FUBARed and which was
Timo Sirainen inscribed:
Have you set mbox_very_dirty_syncs=yes? That should be helpful.
Oh, that sounded like a risky option.
I do have mbox_dirty_syncs enabled.
Are there still "safety checks" with the extra down-and-dirty sync option?
Joseph Tam-a-lyne wrote:
> doveadm user $user
>
>
On 12 Jun 2017, at 2.09, M. Balridge wrote:
>
>> 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.
On that note, has anyone written a tool that "harmonises" users mail
directories' permissions - ideally reading the dovecot configuration to assess
where *THE* mail directories are actually used by dovecot?
doveadm user $user
which will supply the second half: it will spit out the
David "Show Me The Vintage!" McGuire wrote:
> I for one am finding this thread extremely entertaining. I have to
> wonder how you'd sound if you came across a machine that was actually
> OLD. ;)
Well, I am fond of "old" hardware, which may still be on the wrong side of the
New/Old divide for
I do know that this little box of horrors has 200-300MB mbox INBOXes on an
ext3 filesystem formatted in 2005. I am very nervous about converting them to
Maildir at this point.
Fortunately, it just involves reformatting the data and a little
reconmfiguration of dovcot. If you can find the
On 06/09/2017 05:13 PM, M. Balridge wrote:
> I do know that this little box of horrors has 200-300MB mbox INBOXes on an
> ext3 filesystem formatted in 2005. I am very nervous about converting them to
> Maildir at this point. If I could get someone (or something) to the site and
> replace it with
> >> Warning: Transaction log file
> /home/luser/mail/.imap/INBOX/dovecot.index.log
> >> was locked for 95 seconds (rotating while syncing)
>
> Timo recently explained to me it's probably caused by slow I/O or
> processing. This explanation is consistent with my observation that
> the users who
On 9 Jun 2017, at 5.03, M. Balridge 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
"M. Balridge" writes:
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 resemble that remark.
Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
I was recently asked to upgrade some neolithic aged software (UW-IMAP,
sendmail 8.12.x, apache 1.3, amongst other horrors).
The box is physically remote, so an aggressive "new flush" wasn't an option.
I've been able to upgrade the compiler to gcc-3.4, openssl to 1.0.2k, glibc,
php to something
13 matches
Mail list logo