Date: Sun, 13 Jan 2013 17:32:12 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Ben Morrow <ben@morrow.me.uk> Cc: freebsd-stable@freebsd.org Subject: Re: Determining which process needs to be restarted after update Message-ID: <20130113163212.GA20259@dft-labs.eu> In-Reply-To: <20130113014256.GA6645@anubis.morrow.me.uk> References: <201467687.20130112121822@takeda.tk> <20130112232914.GA4922@anubis.morrow.me.uk> <20130113014256.GA6645@anubis.morrow.me.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 13, 2013 at 01:43:03AM +0000, Ben Morrow wrote: > 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. > Actually dcache in linux is able to return names for unlinked files. Such entries have ' (deleted)' appended. And it looks like it is able to do that reliably. Another thing is that this tool should have list of updated files, so matching it with ' (deleted)' files is trivial. Note that I didn't check how zypper ps actually works, just answering your concerns in this area. I think this approach is incorrect anyway, see below. > > 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. > This does not allow you to distinguish from unlinked non-library file mmapped this way. > > 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. > I don't see how it can produce false positives. It will miss processes running unpackaged stuff though. When it comes to updated files, the following may happen: 1. process is running old binary 2. process is running old libraries 3. process has old files opened 4. process read some old files and these are now closed So if you want to make sure that all processes are working with updated stuff dependency walk is the only way. And even if you want to ignore 4, since procstat does not give you names of delted inodes, you have to do dependency walk anyway. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130113163212.GA20259>