On 28/02/06, Paul Schoonderwoerd paul@pollux-it.nl wrote:
On Tuesday 28 February 2006 13:29, Will McDonald wrote:
IMHO looks more like a POP issue to me although the time representation seems odd. But this could be nfs-client related. What does it look like when you mount a share locally on the server where it is exported ?
I'll have a look at that now. Right, weirdly, exporting to localhost and then mounting that locally on the NFS server, the timestamps look OK, but they're still borked on clients.
[root@tempmailstore1a mnt]# mount -t nfs localhost:/mnt/drbd/home/ /mnt/localnfs/ [root@tempmailstore1a mnt]# cd /mnt/localnfs/vpopmail/domains/${domain.tld}/0/G/dailytest/Maildir/new/ [root@tempmailstore1a new]# ls -ltr total 8 -rw------- 1 vpopmail vchkpw 854 Feb 28 13:40 1141126119.27119.mailserv1,S=773
I'm thinking locking/timing/uid's/accessrights...
The UID/GIDs are identical on the new clients and both old and new servers (Qmail/VPOPMail gets very overwrought if you change UIDs :)).
It could be a locking thing, I noticed this on the nanhat list earlier...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167192
Is there anything in the log about POP ? Is it possible to run in debug-mode to generate some ?
POP works just fine in terms of authentication, it's just not seeing new files in the Maildirs until 'x' amount of time has passed, where 'x' is orders of magnitude greater than NFS attribute caching could/should account for.
Optional: dovecot imap server will also do pop.
I dread to think what would be involved in migrating all the Qmail/VPOPmail architecure we have over to something else. It's inherited, and entrenched. :o\
Will.