Determining which process needs to be restarted after update

[Ben Morrow]

Quoth Mateusz Guzik <mjguzik at gmail.com>:
> On Sat, Jan 12, 2013 at 11:29:14PM +0000, Ben Morrow wrote:
> > Quoth Derek Kulinski <takeda at 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