Warner Losh wrote:
> If advisory locks won't work (and they almost always will for things
> like this), then you could walk the process tree. For all processes
> that aren't suspended or yourself, send a SIGSTOP, keep a list.
I don't think advisory locks will work - the other process is sendmail... I
have to keep it from opening any of it's config files, whilst I 'rename' out
of place the old ones (keeping any fd's to them intact) and rename in the new
ones...
Killing / stopping the root sendmail doesn't work (as children making multiple
deliveries still apparently open these files at will) - and killing all of
them isn't really an option either (as too many emails will be dropped, this
means junking say, a 90% of the way through 3mb email delivery - only to have
to resend/process it again from scratch).
> going through the tree while you keep finding processes. SIGSTOP
> can't be caught or blocked, so you know you've stopped them). Do your
> operation, then send SIGCONT to all the processes that you sent a
> SIGSTOP to.
I like the sound of this... The only race I could see would be if one of the
sendmail's had issued the open() to open the file, but on the other hand, it
will either get 'stopped' before this syscall (in which case it will open()
the 'new' file when it gets continued), or it will get stopped after the
open() in which case the FD it has will still be valid, as the old file still
exists and has only been renamed... It can't get stopped in the middle of the
open() call - can it? [Now I am being paranoid! - I'm sure it can't... Yet in
FreeBSD...]
> Of course, this will likely be much harder than doing
> advisory locking, but might be a way that you might be able to exactly
> what you want.
Presumably for advisory locking, I'm right in thinking I'd have to tinker with
the sendmail source, so it also uses advisory locking etc?
> Well, you may need an exception list of processes if your files aren't
> on a local disk, but if they aren't on a local disk, this whole
> excersize is pointless, right?
All the files are local... They're re-built from a database, on an
all-to-often basis... (Hence the need to HUP sendmail, without killing all
it's kids etc.)
> P.S. Can you tell I'm partial to advisory locks?
Yes... :) - They would be a better way of doing it! - But I'd rather not mess
with Sendmail :)
Also, A big "Thanks" to all that replied... I've posted two questions to
-hackers recently, and netted two very good replies...
-Karl
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
