[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrew Daviel
Subject: Re: Jamming up with mutex_lock (GECOS patch) - fixed (maybe)
Date: Mon, 9 Jul 2007 15:05:47 -0700 (PDT)

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:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]