Jeroen Scheerder:
Will truss away when the problem is there, and try to get some useful info.
Tracing does not reveal anyting interesting, yet.
The problem (extreme slowless; dozens of minutes to write a message to a mailbox, or read a message from one) occurs now.
I've trussed the relevant imap process:
poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) (sleeping...) poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 6) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0 poll(0x00095038, 1, 0) = 0 poll(0x00095038, 1, 999) = 0
[snip a few thousand repetitive lines]
... and so on, and so forth. Another imap process, that polls my inbox, looks very different: I see stat64()'s there, and mmap()/munmap()'s, and reads with stuff that looks convincingly like proper IMAP talk.
The same mailbox that is problematic (apparently) can be accessed just fine using mutt directly, without mutt complaining about existing locks (as it does, when there *are* locks in place).
So this imap process just seems to be idling. Hmm.