From owner-freebsd-stable@FreeBSD.ORG Sun Jan 13 01:43:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5479CC96 for ; Sun, 13 Jan 2013 01:43:10 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 21EA7174 for ; Sun, 13 Jan 2013 01:43:09 +0000 (UTC) Received: from anubis.morrow.me.uk (host109-150-212-220.range109-150.btcentralplus.com [109.150.212.220]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id B4887450DE; Sun, 13 Jan 2013 01:43:06 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.4.1 isis.morrow.me.uk B4887450DE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1358041387; bh=EImotVA2hpwEDIHCZJjXbff3AZmpFf4iePwJbLi1gko=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=tG0RxUH7tWvmJLYOHRlds6nL2meQNFmUauoBTj6sY3WqQ+P4SD7NOAxsLNy4P1LEz 2y/4BSRVNalZABBMYSO2lTNpT/86lwL1UgyDNBZLisvFwT4k2p8j8vm2oxhGHOxbJQ J5ZYr0TNdampaTGB0LzrNb5u0kC6rGNPsi6ggAeE= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.5 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id C250E82C1; Sun, 13 Jan 2013 01:43:03 +0000 (GMT) Date: Sun, 13 Jan 2013 01:43:03 +0000 From: Ben Morrow To: mjguzik@gmail.com, freebsd-stable@freebsd.org Subject: Re: Determining which process needs to be restarted after update Message-ID: <20130113014256.GA6645@anubis.morrow.me.uk> References: <201467687.20130112121822@takeda.tk> <20130112232914.GA4922@anubis.morrow.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130112234704.GA5849@dft-labs.eu> X-Newsgroups: gmane.os.freebsd.stable Organization: morrow.me.uk User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 01:43:10 -0000 Quoth Mateusz Guzik : > On Sat, Jan 12, 2013 at 11:29:14PM +0000, Ben Morrow wrote: > > Quoth Derek Kulinski : > > > > > > I personally really like OpenSuSE command which is: zypper ps > > > What it does is it lists all processes that have files opened that > > > currently don't exist (i.e. link count is 0). This helps tremendously > > > in determining which processes need to be restarted after an update. > > > > > > Is there something similar for FreeBSD? I was thinking of using > > > lsof +L1, but on FreeBSD that command is not capable of displaying > > > names of files that were deleted, many entries returned are for > > > example processes that have open sockets. It also does not list names > > > of the deleted/replaced files. > > > > > > Is there a tool that is capable to do such task, or maybe some > > > additional options to lsof? I'm not too familiar with it myself. > > > > procstat -fa, look for entries with 'v' in the 'T' column and '-' in the > > 'NAME' column (or get awk to look for you). You may also want to check > > the 'V' column: see the manpage for the codes. This won't tell you what > > the file used to be called before it was deleted: I don't think the > > kernel keeps that information. > > > > This has at least 2 problems: > - it will not show shared libraries (-v is required) That's a good point. > - it will report processes with open unlinked files, which is completely > normal Isn't that exactly what the OP wants to find? I agree that it happens for reasons other than a software update, but I don't see how that can be avoided. Presumably the SuSE tool mentioned would give the same false positives. > But even if we use -v, I don't think we can reliably distinguish > "regular" unlinked file mapping from shared library mapping (for > unlinked files we will get - as a name, just like in -f case). I didn't > dig into this though. A process currently running an unlinked shared library will have at least one procstat -v entry with 'x' in the 'PRT' column, 'vn' in the 'TP' column and nothing in the 'PATH' column. > Instead I would go upwards in package dependency tree and for each daemon > check if it is running (should be doable without much hackery). Checking > for all binaries may be more problematic. Yes, something like that might be better, though that will also get a lot of false positives. Ben