Woops, forgot the script.  Here it is:

<?php

imap_open($argv[1], "", "");

?>

You probably could have figured this out :-).  You need an mbox file on which to run imap_open; there's no way to eliminate that dependency.

Can't reproduce.
I don't see any error messages and the script works fine.

$ ls -l /var/mail/jik; php /tmp/imap_open.php /var/mail/jik & php /tmp/imap_open.php /var/mail/jik
-rw------- 1 jik mail 871 Jan  4 13:44 /var/mail/jik
[1] 31702
starting to open mailbox
starting to open mailbox
successfully opened mailbox
PHP Notice:  Unknown: Trying to get mailbox lock from process 31702 (errflg=1) in Unknown on line 0
[1]+  User defined signal 2   php /tmp/imap_open.php /var/mail/jik
$ 

New version of the script:

<?php
print "starting to open mailbox\n";
imap_open($argv[1], "", "");
print "successfully opened mailbox\n";
?>

I don't know why you can't reproduce it; it reproduces easily for me, as shown above.  The c-client documentation and source code make it clear that this is going on, so unless you can confirm that PHP is installing a USR2 handle when locking mailboxes, I'm pretty sure it's a problem.

Did you run the script twice at the same time as I said in my report?  That's the only way you're going to be able to reproduce it, since it requires contention from two different processes.

Also, let me remind you that it won't happen if the mailbox file is empty; it needs to have messages in it, or c-client won't lock it.

>Did you run the script twice at the same time as I said in my report? 
Yes. And the mailbox is not empty.

There's a patch which makes this problem go away at http://stuff.mit.edu/~jik/php-5.1.1-imap-usr2.patch.txt.  However, rather than using the #if statement I used to figure out whether to enable the relevant code, you may want to insert a check for the function arm_signal in the c-client library in the configure script, define a cpp symbol if the function exists, and use my code if that cpp symbol is defined.

Exactly what c-client version you linked PHP with?
And how was it compiled?

libc-client-2002e-18.1 RPM from Fedora Core.  I checked the current c-client sources from washington.edu and they seem susceptible to this problem as well, judging from an examination of the source code.  The USR2 functionality has been in c-client since 1993, as far as I can tell.

I get the same notices, which seem quite harmless anyway. And your patch did not make any difference whatsoever.

Please look carefully at the output.  The notices are not "harmless".  Note that the message "successfully opened mailbox" only appears *once*.  It should appear twice, because there are two processes who both want to open the mailbox.  It only appears once because one of the two processes is killed by a USR2 signal as I've described.

I don't know why the patch I sent didn't help for you.  It reliably solves the problem for me.  Perhaps I picked bad preprocessor symbols and it's not actually getting compiled into the object code on your system.  Can you put debugging code in to see if the arm_signal calls are actually happening?

Thanks.

Why would you want to allow opening same mailbox by two simultaneous processes?

You *don't* want to allow the simultaneous opening of a mailbox by two processes.  The whole point of locking is to *prevent* the simultaneous opening of a mailbox by two processes.  What the locking is *supposed* to do is to make one process *wait* for the other one, but what it does instead, if you don't catch the USR2 signal, is for the process that got the lock first to *die* after *being killed* by the other one.  This is not correct behavior.

Incidentally, I just tested with a newly compiled c-client 2004g and confirmed that the problem persists there without my patch.

This bug is still around and can wreak havok for a drupal site that lets 
users submit content via machine-local mail. Could someone *please* 
commit it already?

The problem with PHP setting a handler for SIGUSR2 is that when we are 
running as a SAPI module inside some other process like Apache or 
anything using LinuxThreads, grabbing SIGUSR2 may cause problems.  
Newer Linux kernels provide reserved internals signals for LinuxThreads 
to use, and Apache should only be using SIGUSR1, but how confident are 
you that PHP grabbing this signal isn't going to break it in some 
environments?  It may fix the problem in yours, but if it breaks it in 
many others that is something we need to deal with.