[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Including a warning to restart daemons after an
From:       Patrick Lauer <patrick () gentoo ! org>
Date:       2011-08-22 9:37:29
Message-ID: 4E522359.80701 () gentoo ! org
[Download RAW message or body]

On 08/21/11 13:29, Anthony G. Basile wrote:
> Hi everyone,
> 
> After updating libraries, I always run something like
> 
>     lsof -x / | grep DEL
> 
> to see if any running binaries are linking to old libraries that were
> just updated and then I manually restart them.  This is particularly
> important if the update addresses some security issue in the library.
> 
> Debian and its derivatives take the drastic step of restarting the
> daemons for you, which is, in my opinion, undesirable.  I'd like to be
> in control of when I upgrade and when I restart my daemons.

For some users restarting might be acceptable, I would rather not have
to figure out why the DB just went down and can't restart during an
update :)
And the checks (like preserved-libs) that run after pkg installation can
take so much time that I'd want them to be user-controllable - sometimes
you just don't want to wait 5 minutes after a package merge to regain
control of your shell

So I think there are three cases we need to consider:
1) autorestart. FEATURES-controlled maybe?
2) indicator - warn, but do not take any action
3) completely disabled, "don't waste my time"
> 
> OpenSuse has a nice solution.  After an upgrade, it tells you that there
> are some running binaries still linking against the old libraries and
> asks you to run "zypper ps" to see them in a pretty format.  You can
> then restart at your discretion.
> 
> I'm wondering if we should add something like that?  Something to be run
> post_inst() and just ewarn the user.  It could be a small eclass on its
> own that maintainers can elect to inherit and use in ebuilds for daemons.

eclass sounds hackish since it's portage doing the work. A postinst hook
or a direct portage feature sounds more reasonable to me.

> What do you think?  If its a good idea, is implementing it in an eclass
> the way to go?
Yes, no :)

Have fun,

Patrick



[prev in list] [next in list] [prev in thread] [next in thread]