[Dovecot] deliver and stale NFS file handles
Hello, since updating two of our backup mailservers from dovecot 1.1.16 to 1.2.4 i get the following errors from dovecot-deliver when receiving (smtp) mail.
Oct 16 00:10:42 mail3 dovecot: deliver(user): write_full(/home/r/user/.temp.backupmail.22774.d17050a07b2108e8) failed: Stale NFS file handle Oct 16 00:10:42 mail3 dovecot: deliver(user): copy: i_stream_read() failed: Stale NFS file handle Oct 16 00:10:43 mail3 dovecot: deliver(user): msgid=<d0acb2021be1922ae2d35fbd6b09994c.squirrel@www.physik.tu-berlin.de>: save failed to INBOX: Internal error occurred. Refer to server log for more information. [2009-10-16 00:10:42]
It nearly never happens with text/plain mails but _very_ often when mails have attachments of some different type. This is inside a 7.2-RELEASE-p2 FreeBSD jail. The NFS export is mounted from the machine that is running the jail. Locking with lockf works.
Following is the output of dovecot -n
from the mailserver.
Please tell me if you need any further information.
Thanks in Advance, Leon
$ dovecot -n # 1.2.4: /usr/local/etc/dovecot.conf # OS: FreeBSD 7.2-RELEASE-p2 amd64 log_path: /var/log/dovecot.log protocols: imaps pop3s managesieve listen: mail3.physik.tu-berlin.de ssl_cert_file: /etc/private/backupmail.pem ssl_key_file: /etc/private/backupmail_privatekey.pem login_dir: /var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login login_processes_count: 6 login_max_processes_count: 256 verbose_proctitle: yes first_valid_uid: 200 first_valid_gid: 300 mail_privileged_group: mail mail_location: maildir:~/maildir mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve imap_client_workarounds(default): delay-newmail netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(imap): delay-newmail netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(pop3): imap_client_workarounds(managesieve): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh pop3_client_workarounds(managesieve): namespace: type: private separator: / inbox: yes list: yes subscriptions: yes namespace: type: private separator: / prefix: mail/ location: mbox:~/mail list: yes subscriptions: yes lda: postmaster_address: postmaster@physik.tu-berlin.de log_path: info_log_path: mail_plugins: sieve quota_full_tempfail: yes sendmail_path: /usr/sbin/sendmail auth default: mechanisms: gssapi plain login username_format: %Lu krb5_keytab: /etc/mail3.krb5.keytab gssapi_hostname: backupmail worker_max_count: 120 passdb: driver: pam args: session=yes failure_show_msg=yes max_requests=100 dovecot userdb: driver: passwd args: blocking=yes socket: type: listen client: path: /var/run/dovecot/auth-client mode: 432 master: path: /var/run/dovecot/auth-master mode: 384 plugin: sieve: ~/.dovecot.sieve sieve_dir: ~/.sieve
On Fri, 2009-10-16 at 14:25 +0200, Leon Meßner wrote:
Oct 16 00:10:42 mail3 dovecot: deliver(user): write_full(/home/r/user/.temp.backupmail.22774.d17050a07b2108e8) failed: Stale NFS file handle
It nearly never happens with text/plain mails but _very_ often when mails have attachments of some different type. This is inside a 7.2-RELEASE-p2 FreeBSD jail. The NFS export is mounted from the machine that is running the jail. Locking with lockf works.
It happens with mails that are larger than 128 kB. Then Dovecot creates a .temp.* file and unlink()s it and tries to keep using it as a temporary file. I thought this would have worked with all NFS clients, since at least Linux then renames the file to .nfs.* file and deletes it automatically..
Can you try what happens if you do in your FreeBSD on NFS system:
touch foo tail -f foo& rm -f foo fg
Does it complain about stale NFS handle?
The reason this wasn't happening with older versions was because deliver did this in /tmp instead of in user's home.
Timo Sirainen schrieb:
On Fri, 2009-10-16 at 14:25 +0200, Leon Meßner wrote:
Oct 16 00:10:42 mail3 dovecot: deliver(user): write_full(/home/r/user/.temp.backupmail.22774.d17050a07b2108e8) failed: Stale NFS file handle
It nearly never happens with text/plain mails but _very_ often when mails have attachments of some different type. This is inside a 7.2-RELEASE-p2 FreeBSD jail. The NFS export is mounted from the machine that is running the jail. Locking with lockf works.
It happens with mails that are larger than 128 kB. Then Dovecot creates a .temp.* file and unlink()s it and tries to keep using it as a temporary file. I thought this would have worked with all NFS clients, since at least Linux then renames the file to .nfs.* file and deletes it automatically..
Can you try what happens if you do in your FreeBSD on NFS system:
touch foo tail -f foo& rm -f foo fg
Does it complain about stale NFS handle?
Yes, it does complain: "tail: (null): Stale NFS file handle" I tried the same on /tmp, which is based on UFS, and it worked. Do you think this is a new FreeBSD bug? And if so, are you going to report it?
MfG Christoph
On Sat, 2009-10-17 at 10:52 +0200, Christoph Berkemeier wrote:
Does it complain about stale NFS handle?
Yes, it does complain: "tail: (null): Stale NFS file handle" I tried the same on /tmp, which is based on UFS, and it worked. Do you think this is a new FreeBSD bug? And if so, are you going to report it?
Well, I guess it's more like a missing feature that Solaris and Linux has.. I guess I'll have to change Dovecot to delete the temp file only after it's done with it. The problem with that is that if it crashes before that it leaves those temp files lying around.
participants (4)
-
Christoph Berkemeier
-
Edgar Fuß
-
Leon Meßner
-
Timo Sirainen