RE: procmail: Locking "tmp.lock" (smartlist)

At 4:02 PM -0400 7/13/05, Kim Ridenour is rumored to have typed:

> The last two lines have now repeated for 4 hours. 4,441 procmail processes
> have been started and we're still going.

   (*sigh*) That is NOT what you described in your earlier message. The
existance of the lock file is not a problem (this is expected behavior). The
file not _unlocking_ clearly is.

> Seems fairly obvious to me that there's a problem here.

   Stop mail into the system, su to the SmartList user and delete the
tmp.lock file. Keep an eye on the directory; the file WILL be re-created with
all those processes running, and so long as the timestamp continues to
change, and the number of locked processes drops, do nothing. Otherwise,
continue to delete the lock file occasionally. (My guess is you'll be able to
watch the processes take care of themselves using ps or top, and won't need
to do anything after deleting the existant lockfile. But it's only a hunch.)

   Assuming you didn't accidentally create a permissions problem, I'd suggest
you check the machine over completely; I've seen this happen _once_ in the
(far too many) years I've been using procmail, and shortly afterwards I lost
a drive. I am not suggesting you are having a hardware fault, only recounting
a single isolated anecdotal experience I had many years ago which may be
coincidental.

         Charlie