From owner-freebsd-hackers Thu Aug 17 18:53:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.129.65]) by hub.freebsd.org (Postfix) with ESMTP id 6B26F37BC82 for ; Thu, 17 Aug 2000 18:51:10 -0700 (PDT) Received: from viper.dmpriest.com (viper.dmpriest.com [195.188.177.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65DE26E311E for ; Thu, 17 Aug 2000 13:59:56 -0700 (PDT) Received: from tdx.co.uk (lorca.tdx.co.uk [195.188.177.195]) by viper.dmpriest.com (8.9.3/8.9.3/Kp) with ESMTP id VAA04215; Thu, 17 Aug 2000 21:58:41 +0100 (BST) Message-ID: <399C5201.5B6911CE@tdx.co.uk> Date: Thu, 17 Aug 2000 21:58:41 +0100 From: Karl Pielorz Organization: The Digital eXchange X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Critical (or equivalent) section in Userland? References: <399BA212.A84240AE@tdx.co.uk> <200008171723.LAA12924@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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