Hello,
what about turning on the logfile in your rc script? Or even in
/etc/procmailrc
LOGABSTRACT=yes
VERBOSE=yes
VERBOSE=yes I have on. LOGABSRACT I didn't know about, but it's noted for
next time;-)
try also:
ftp://vic.cc.purdue.edu/pub/tools/unix/(lslk|lsof)
lslk didn't show anything I could understand (it displays inode numbers,
and it took me too long to figure how to translate) , and didn't reveal
any program names of significance (particularly NOT procmail).
lsof I didn't think of; I have both installed.
I only ever saw one lock file.
Here what I have done:
I have rebooted. That did not cure the problem.
I renamed /var/spool/mqueue to isolate the troublesome mail and created a
new one. More incoming mail had problems.
There have been several folders involved, protected by lockfiles procmail,
lib-www and inbox. I changed the lockfile names, and I have just processed
all my mail. Martin's reply is one of the emails that was stuck.
It may be that there's a problem if I explicitly set a lockfile, say
procmail, for a folder called procmail. I got lots of messages like these
for the folders that gave trouble:
procmail: Locking "inbox"
procmail: [19971] Fri Apr 7 18:55:05 2000
procmail: Locking "inbox"
procmail: [19971] Fri Apr 7 18:55:13 2000
I have changed the explicitly-named lock files just in case. My
speculation is that procmail was NOT suffixing .lock as I thought it did,
and the lock failure arose because of a name conflict
On Thu, 6 Apr 2000, John Summerfield wrote:
I'm running procmail on RHL 5.x with kernel 2.2.13, glibc 2.0
This is getting terrible urgent:
[summer(_at_)emu summer]$ find .Mail/ -name \*.lock
.Mail/Llists.lock
[summer(_at_)emu summer]$ ps x --sort:start_time | grep procmail
14529 ? S 0:00 procmail -f
procmail-request(_at_)informatik(_dot_)rwth-aachen(_dot_)de
-Y -a
19073 ? S 0:00 procmail -f www-lib-request(_at_)w3(_dot_)org -Y -a -d
summer
19076 ? S 0:00 procmail -f www-lib-request(_at_)w3(_dot_)org -Y -a -d
summer
19130 ? S 0:00 procmail -f www-lib-request(_at_)w3(_dot_)org -Y -a -d
summer
25111 ? S 0:00 procmail -f
procmail-request(_at_)informatik(_dot_)rwth-aachen(_dot_)de
-Y -a
6222 ? S 0:00 procmail -f
general-return-3832-summer=os2(_dot_)ami(_dot_)com(_dot_)au(_at_)j
akart
10903 ? S 0:00 procmail -f
procmail-request(_at_)informatik(_dot_)rwth-aachen(_dot_)de
-Y -a
10976 ? S 0:00 procmail -f tomcat-user-return-815-summer=os2.ami.com.a
u(_at_)jak
11338 ? S 0:00 procmail -f minordomo-owner(_at_)ndn(_dot_)net -Y -a
-d summer
11424 ? S 0:00 procmail -f tomcat-user-return-816-summer=os2.ami.com.a
u(_at_)jak
11607 ? S 0:00 procmail -f
owner-linux-kernel-digest-outgoing(_at_)vger(_dot_)rut
gers.
11654 ? S 0:00 procmail -f tomcat-user-return-818-summer=os2.ami.com.a
u(_at_)jak
11676 ? S 0:00 procmail -f tomcat-user-return-819-summer=os2.ami.com.a
u(_at_)jak
11701 ? S 0:00 procmail -f tomcat-user-return-820-summer=os2.ami.com.a
u(_at_)jak
11746 ? S 0:00 procmail -f tomcat-user-return-821-summer=os2.ami.com.a
u(_at_)jak
11927 ? S 0:00 procmail -f minordomo-owner(_at_)ndn(_dot_)net -Y -a
-d summer
11948 ? S 0:00 procmail -f
procmail-request(_at_)informatik(_dot_)rwth-aachen(_dot_)de
-Y -a
12414 ? S 0:00 procmail -f
procmail-request(_at_)informatik(_dot_)rwth-aachen(_dot_)de
-Y -a
12438 ? S 0:00 procmail -f
owner-linux-kernel-digest-outgoing(_at_)vger(_dot_)rut
gers.
[summer(_at_)emu summer]$
These procmails are stuck on a locked lock file. Short of rebooting, how
do I clear it?
If someone doesn't get back soon, I'm going to try something desperate;
perhaps killing off 14529 which seems to be the one at the head of the
queue.
There is only the one lock file.
Needless to say, I need a reply off-list; this list is caught in the
logjam.
--
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.
--
Martin Mokrejs - PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
<mmokrejs(_at_)natur(_dot_)cuni(_dot_)cz> Faculty of Science, The Charles
University
--
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.