Date: Fri, 18 Aug 2000 07:49:32 +0100 From: Karl Pielorz <kpielorz@tdx.co.uk> To: Warner Losh <imp@village.org> Cc: hackers@FreeBSD.ORG Subject: Re: Critical (or equivalent) section in Userland? Message-ID: <399CDC7C.F68E634@tdx.co.uk> References: <399C5201.5B6911CE@tdx.co.uk> <399BA212.A84240AE@tdx.co.uk> <200008171723.LAA12924@harmony.village.org> <200008172140.PAA14347@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: > Kill sendmail's root process. That's the best you can do. It won't > impact anything, it will prevent the reading of the queue files (and > the config files) and the children will just run with the old copies. > then you wait for all the children to die (with a reasonable > timeout). Then you do your change, then restart sendmail. That's the > best you can hope for. Unforuntately this doesn't work, as sendmails numerous children live for too long (the machine is a busy MX, and people increasingly mail 5Mb+ files around) Also adding to the children's lives is the fact that sendmail uses cached connections to delivery multiple messages to the same destination MX, which leads to even longer 'death' times, and can also result in Sendmail's kids looking up domains etc. in the config files :( [At least, that's what appears to be happening after a lot of observation]... However, 'killall -SIGSTOP sendmail' - appears to work very nicely... With a 'killall -SIGCONT sendmail' putting things back to normal. I'm also doing the stop twice for good measure incase anything was forking at the time. I guess only time will tell, but the signal idea seems the best so far, considering the other restrictions :) Regards, Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?399CDC7C.F68E634>