similar to: locking methods

There are three applications that have their mitts on files on my mail server, which is running AIXV5.3 and UWIMAP and mbox format. The mail folders and INBOXES are native to that machine, but also are NFS exported to a login server and a mailing list server. All three machines are running the lockd daemon. Everybody wants to lock differently 1) procmail (delivering for sendmail), which

We're running dovecot 2.3.10 on two different servers (two different environments). Both very similarly configured (sendmail and procmail for mail delivery); same OS and patch levels. One environment has nearly 10,000 users and hasn't seen problems. The other environment has just a handful of users, but one user is very active with email and has a fairly complicated procmail

I have Dovecot 1.0 in trial use by the IT staff, and have some locking questions Background, the mail server runs procmail, sendmail and NFS exports the user homedir and mailbox to a) a login shell host and b) a mailing list services host. It runs UWIMAP on the usual ports and dovecot on a arbitrary port number. Because of concern with NFS and file access contention. I have the following

Any known issues with these locking strategies? (RHEL 4.x default) Dovecot: mbox_locks = fcntl Procmail Locking strategies: dotlocking, fcntl() We're considering moving to all dotlocking after a recommendation from RedHat, even though we're not using NFS at all. Thanks!

Hello, Running dovecot 1.1.6 on centOS 5 and RHEL 5. With the settings: pop3_lock_session = yes mail_privileged_group = mail mail_location = mbox:~/:INBOX=/var/spool/mail/%u mbox_read_locks = fcntl mbox_write_locks = dotlock fcntl and /var/spool/mail permissions: drwxrwx--x 2 root mail 4096 Nov 19 10:16 mail/ Trying to connect via POP3 results in this error: --- Nov 19 09:31:01

Hello, I'm attempting to move form qpopper 4.1 to Dovecot 2.2.5 on Linux. When a user checks POP mail qpopper seems to make a .username.pop temporary file in the same /var/mail directory as the mbox INBOX file. Watching what dovecot does I don't see this happening. Is this .pop file a lock file or just a temporary file? If its a temp file does dovecot do the same thing elsewhere?

I'm attempting to replace (a) a very old setup that has POP (qpopper) access to inboxes and a separate UW IMAP server that provides folders, with (b) a shiny new mail setup with dovecot providing both inboxes and IMAP support. For the new mail server I created a virtual machine running a minimal Fedora 16 installation and installed sendmail, MIMEDefang, SpamAssassin, ClamAV, procmail, and

Hi my last post got no replies so i am trying again. FC3 dovecot 1.0 stable, 1 user has a lock file using mbox under /var/spool/mail/username from the lock file the pid files are File Descriptor Type File size Inode Path Current dir Directory 4096 6426371 /home/domain/domain127 Root dir Directory 4096 2 / Program code Regular file 1212428 1229832

Hello, What is the proper solution to the problem below the sig? For a similar issue, Phillip Guenther, procmail's maintainer, at <http://article.gmane.org/gmane.mail.procmail/1623/match=error+writing+var+spool+mail> suggests "chmod g+s /usr/bin/procmail", but I'm reluctant. There are also suggestions that in this configuration the packager must make certain that

Dear Colleagues, I use exim's appendfile transport, procmail and a local mutt on my system, they all (to my knowledge) use lockfiles when working with mboxes. However, `doveconf | grep lock` says dotlock_use_excl = yes lock_method = fcntl mail_max_lock_timeout = 0 mbox_dotlock_change_timeout = 2 mins mbox_lock_timeout = 5 mins mbox_read_locks = fcntl mbox_write_locks = dotlock fcntl

Hello Timo, I'm running dovecot-1.0.rc15 (imap and pop) postfix-2.3.5,1 procmail-3.22_6 (which is my LDA) on FreeBSD 6.1-STABLE I'm still using the mbox format (I'm planning to migrate to Maildir soon), mailboxes are on an NFS filesystem. I regulary see stale dotlocks files (either from dovecot (29 bytes, hold the pid of the process) or procmail (1 byte) and processes

I'm running Dovecot 1.1 RC1. I believe I've done all the due diligence for making things working correctly over nfs. But I run into locking issues if I run over nfs. procmail is doing the delivery over nfs. uw-imap was ruining over nfs. dovecot is fine if its on the nfs server (i.e. it has local access to the disk, no nfs) I run into lock deadlocks if I run dovecot over nfs Users

I just migrated from a FreeBSD/Sendmail/UW-IMAP setup to RHEL 3/Postfix/Dovecot (1.0a5 currently). Both systems used Procmail as the final delivery agent (into inboxes or . Since the changeover, things have *mostly* been going ok, but I've been having some problems that I think are locking-related. I'm getting reports from users about IMAP hangs (mostly from Thunderbird). Sometimes I see

Hi, I'm (still) evaluating dovecot for a switch from UW in the near future. All the following happens on a Solaris server. Functionally, all is well. However, I see strange phenomena. Normally, dovecot is pretty swift. Every now and then, though, things slow down to a crawl. Everything seems to be working, still, but a few orders of magnitude slower. A copy of an outgoing message (of a

Hello, I'd like to make sure my understanding of the mbox locking strategy is correct : - "mbox_dotlock_change_timeout" directive : a process seeing that an already locked (by another process) mbox he want to access hasn't change for this amount of time, allows himself to override the lock ? If it's using fcntl, is it only possible to override ? -

Hello! I run the following environment: UW imapd pine sendmail procmail mbox format I migrated from UW imapd to dovecot. It is pretty faster than UW imapd. To ensure a compatible environment I did the following configuration changes in /etc/dovecot.conf: protocols = imaps default_mail_env = mbox:~:INBOX=/var/mail/%u mail_full_filesystem_access = yes mbox_read_locks = fcntl mbox_write_locks

I have to make dotlock work because this openwebmail thing only supports one of dotlock or flock, but procmail delivery does dotlock and fcntl. procmail correctly creates a dotlock file in /var/spool/mail/username.lock when delivering, I can watch this with `while :; do ls -la | grep lock; done`. It works fine when lock_method=fcntl, but no dotlock file shows up in /var/spool/mail.

How does IMAP lock the /var/spool/mail/user file? Here's my problem: I'm writing a script to expire old or oversize mail through a series of archive folders. I don't want to take the whole server down to do this, nor does it seem like I would have to lock the user out entirely if I can manage to emulate the locks correctly. I am able to lock /var/spool/mail/user (and ~user/mail/*)

For the record/archive, so some other unfortunate dovecot implementer won't spend weeks figuring out this particular way dotlocks can have problems... here is what was trashing our dotlocks Basically, I was seeing this: May 14 15:59:58 mercury mail:warn|warning dovecot: IMAP(sdean): Our dotlock file /var/spool/mail/sdean.lock was deleted (kept it 1 secs) > May 14 15:59:58 mercury

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 in the 5.4-branch, etc. I have CLucene working, even. I know should take a shotgun