Quoth Mateusz Guzik <mjgu...@gmail.com>: > On Sat, Jan 12, 2013 at 11:29:14PM +0000, Ben Morrow wrote: > > Quoth Derek Kulinski <tak...@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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"