Re: Jamming up with mutex_lock (GECOS patch) - fixed (maybe)

[Andrew Daviel]

On Tue, 26 Jun 2007, Andrew Daviel wrote:

> So the problem is not that the 
> processes are deadlocked, it's that the parent died. I'm still not sure why.

OK, right now things are working. No die-offs, and no orphan processes.

The parent die-off was due to my not closing the user threshold file 
(duh) so that after 1024 emails to users who had one, it died.

The orphan processes (mutex lock) I still don't understand. The child 
process forked off in order to exec spamc was locking up before it got to 
the exec() call. I realized that this bit of code (the child process) 
doesn't have to be threadsafe, so I removed the mutex lock I'd put around 
the getpwent() call there. I also put an alarm() call in. I don't see it
in syslog, but if it is triggering it will kill the child process after 3 
minutes, and sendmail should allow the mail to pass though after 
the milter call times out. Whence, on our system, the mail will pass
though spamc in the local delivery agent (used for rescoring 
multi-recipient mail with per-user whitelists and threshold). There
were about 2 a day, or something like 1 in 5000 emails I think.

Current supposedly working patch:
http://andrew.triumf.ca/email/spamass-milter.patch.jul9

which, as before, implements:
- per user rejection threshold in $HOME/.spamassassin/
- GECOS matching *without* .forward expansion
- mail passthrough if over MAXSIZE (instead of passing to spamc and
  having that pass it through)

--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376  (Pacific Time)
Network Security Manager