Date: Sun, 13 Jan 2013 01:43:03 +0000 From: Ben Morrow <ben@morrow.me.uk> 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> In-Reply-To: <20130112234704.GA5849@dft-labs.eu> References: <201467687.20130112121822@takeda.tk> <20130112232914.GA4922@anubis.morrow.me.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Mateusz Guzik <mjguzik@gmail.com>: > On Sat, Jan 12, 2013 at 11:29:14PM +0000, Ben Morrow wrote: > > Quoth Derek Kulinski <takeda@takeda.tk>: > > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130113014256.GA6645>