On Mon, 21 Jan 2008, Michael Menge wrote: > i used mbexamine user/testuser | less > to check the check the mailbox of testuser. I forgot to quit less over > the weekend and today i discoverd two problems. > > 1. The mailbox was blocked. No new mails were deliverd to this mailbox. The mailbox was left in a locked state. (fcntl() or flock() locks on both cyrus.header and cyrus.index). > 2. After quitting less, the new mails had been delivered multiple > times depending on the retries of lmtpd. I imagine that you had a whole stack of lmtp processes waiting to acquire the lock on the mailbox. I'm a little suprised that something didn't time out, but I guess that the entire message would be sitting in the staging directory before lmtpd attempts to lock the target mailbox. > is this a (known) bug? Are there other cyrus tools which will have the > same effect? unexpunge -l ? Any command line tool which locks a mailbox and then generates output will have the same behaviour. unexpunge would be the obvious example. Whether this is a bug is debatable. Neither mbexamine or unexpunge actually needs to lock the mailbox when they are just dumping mailbox state, but locking is normally the safest course of action. They aren't supposed to be long running processes. -- David Carter Email: David.Carter@xxxxxxxxxxxxx University Computing Service, Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH. ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
