Date: Thu, 17 Aug 2000 21:58:41 +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: <399C5201.5B6911CE@tdx.co.uk> References: <399BA212.A84240AE@tdx.co.uk> <200008171723.LAA12924@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?399C5201.5B6911CE>