Hi!

Short version: Upgrades happen, libs get deleted/replaced; my
script (links below) tells you what processes to restart.

Long version:

I've recently realized that many admins aren't aware of a problem
when upgrading their systems. Usually, people are told to run
revdep-rebuild and do sundry other stuff. But sometimes, a
certain point is missed: deleted-but-mapped files. Yes, we all
know that upgrading say OpenSSL or gnutls means that we should
restart all the services that use those libraries. But sometimes,
we might miss some obscure daemon or a job running in a screen
(so looking at /etc/init.d doesn't help us).

Fortunately, all the relevant information can be found in /proc:
the per-process maps file lists files (and if they're deleted)
and the cmdline file gives us the name of the processes.

So it's a simple shell onliner, right? Yes, that can be done (and
please refrain from posting your solution to that particular
exercise). But Shell onliners tend to be forgotten, and robust
they ain't, especially if you add in stuff like not listing a
deleted shmem segment or similar stuff.

To make a long posting boring: I've hacked up a Python script
that does all that and prints out a nice summary. It's available
from here:

http://schwarzvogel.de/software-misc.shtml

Or, for those who want to go to the tgz directly:

http://schwarzvogel.de/pkgs/lib_users-0.1.tar.gz

Comments/suggestions appreciated.

Regards,
Tobias

On Wed, 28 Jul 2010 11:38:12 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:

> To make a long posting boring: I've hacked up a Python script
> that does all that and prints out a nice summary. It's available
> from here:
>
> http://schwarzvogel.de/software-misc.shtml
>
> Or, for those who want to go to the tgz directly:
>
> http://schwarzvogel.de/pkgs/lib_users-0.1.tar.gz

Is it like checkrestart[1], originally from debian-goodies but hacked
to work on Gentoo Linux?


Cheers,
jer


[1] app-admin/checkrestart

On Wed, 28 Jul 2010 14:53:01 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Wed, 28 Jul 2010 11:38:12 +0200
> Tobias Klausmann <klausman@gentoo.org> wrote:
>
> > To make a long posting boring: I've hacked up a Python script
> > that does all that and prints out a nice summary. It's available
> > from here:
> >
> > http://schwarzvogel.de/software-misc.shtml
> >
> > Or, for those who want to go to the tgz directly:
> >
> > http://schwarzvogel.de/pkgs/lib_users-0.1.tar.gz
>
> Is it like checkrestart[1], originally from debian-goodies but hacked
> to work on Gentoo Linux?

I've tried now and at first I thought python was complaining, then I
discovered that this was the actual intended output. ;-)

The problem I've always had with checkrestart is that it's too neat
(I'd like to see a list of paths to files for each process, for
instance), too much Debian (no verbose mode, discarding instead of
presenting information it can't deal with) and not enough Gentoo. I've
looked into finding time to discover in which ways I could add the
necessary Gentoo-like bells and whistles, but that little project
hasn't moved forward in a good while.

In short, checkrestart's user interface could do with some extras, and
in your lib_users "hack" all of a sudden we need not rely on lsof
anymore (and yes, app-admin/checkrestart could easily drop the
lsb_release DEPEND since we already know which OS we're on - before
anyone reminds me).

Maybe we should put checkrestart as it is right now into a Gentoo
repository and start extending and improving it based on your
experience hacking up lib_users?


jer

Hi!

On Wed, 28 Jul 2010, Jeroen Roovers wrote:
> > To make a long posting boring: I've hacked up a Python script
> > that does all that and prints out a nice summary. It's available
> > from here:
> >
> > http://schwarzvogel.de/software-misc.shtml
>
> Is it like checkrestart[1], originally from debian-goodies but hacked
> to work on Gentoo Linux?

(Note: this is stream-of-conciousness, so it might be a bit
rambling).

It is very similar in scope, but the implementations differ a
lot. While lib_users has no external dependencies aside from a
Python interpreter, checkrestart uses lsof. While that approach
has the advantage of not only catching mapped files but every
open FD, I am thinking about implementing something similar with
lib_users (but using /proc/<pid>/fd/). Can someone chime in on
the question of dlopen()ed libs and whether they turn up as mapped
files?

One annoying thing about checkrestart is that it refuses to work
for non-root users:
$ checkrestart
This program must be run as root
in order to collect information about all open file descriptors
$

This is a /bug/ - some users might just want to know what /they/
have to restart.

Checkrestart doesn't have a --help function (it also has no
options at all, but at least displaying version info would've
been nice).

For a Debian package, manpage etc. are also suspiciously absent.

Checkrestart tries to tell you which init scripts are relevant. I
think that is neither robust nor desirable but a case of
over-engineering.

Checkrestart does not handle the interpreter problem at all,
while lib_users at least tries to give you enough information to
find out what to do.

I've also taken a look at the source code of checkrestart and
it's obvious it has been hacked to work on Gentoo. Also, it has
several pieces of dead code (checking for lsof output that isn't
ever generated, for example). Is the maintainer of the hacks
still around and doing updates? Its last release was in 2008. How
about upstream for the original checkrestart?

Or, to put it in cold, dead numbers:

$ grep -cv ^# $(which checkrestart)|wc -l
399
$ grep -cv ^# lib_users
106

I'll maintain lib_users anyway since I use it on my own systems,
so it won't go away if nobody is interested in it but me.

Regards,
Tobias

On 7/28/10 2:38 AM, Tobias Klausmann wrote:
> To make a long posting boring: I've hacked up a Python script
> that does all that and prints out a nice summary.
> Comments/suggestions appreciated.

It would be interesting to integrated it with portage, similarly to how
it now displays "you have xx configuration files to update". It could
print "you have xx services to restart".

Paweł

On Wed, 28 Jul 2010 15:23:55 +0200
Tobias Klausmann <klausman@gentoo.org> wrote:

> While that approach has the advantage of not only catching mapped
> files but every open FD, I am thinking about implementing something
> similar with lib_users (but using /proc/<pid>/fd/).

The great advantage would be that it also discovers changed runtime
configuration files. Not that it would also disregard "trivial"
updates, of course, but by pointing out the filenames, an admin having
just run etc-update could easily figure that out.


jer

Hi!

On Wed, 28 Jul 2010, Jeroen Roovers wrote:
> > While that approach has the advantage of not only catching mapped
> > files but every open FD, I am thinking about implementing something
> > similar with lib_users (but using /proc/<pid>/fd/).
>
> The great advantage would be that it also discovers changed runtime
> configuration files. Not that it would also disregard "trivial"
> updates, of course, but by pointing out the filenames, an admin having
> just run etc-update could easily figure that out.

I suspect that wouldn't work in most cases since programs
typically close FDs after reading the config file(s)*. The one
program I know of that doesn't, uses the FD to find out the file
changed and does file-was-deleted handling internally.

Still, if config files aren't the only useful case for checking
the FDs, it might be worthwhile to implement.

Regards,
Tobias

* This is a /good/ thing.

Hi!

On Wed, 28 Jul 2010, "Paweł Hajdan, Jr." wrote:
> It would be interesting to integrated it with portage, similarly to how
> it now displays "you have xx configuration files to update". It could
> print "you have xx services to restart".

Definitely. One of the reasons why I expressly mention dual- or
multiple-licensing in the README is so that it's clear that
inclusion of the code (or adaption) is encouraged. I know very
little about portage internals (or any other package manager, for
that matter), so it's not high priority for me.

Regards,
Tobias

Hi!

And hot off the tar, here's v0.2:
http://www.schwarzvogel.de/software-misc.shtml
http://www.schwarzvogel.de/pkgs/lib_users-0.2.tar.gz

Several suggestions were implemented, including more Pythonic
code in a few spots and new patterns for the blacklist.

Please test and comment.

Regards,
Tobias