Gentoo Archives: gentoo-dev

From: Patrick Lauer <patrick@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Including a warning to restart daemons after an update.
Date: Mon, 22 Aug 2011 09:38:16
Message-Id: 4E522359.80701@gentoo.org
In Reply to: [gentoo-dev] Including a warning to restart daemons after an update. by "Anthony G. Basile"
1 On 08/21/11 13:29, Anthony G. Basile wrote:
2 > Hi everyone,
3 >
4 > After updating libraries, I always run something like
5 >
6 > lsof -x / | grep DEL
7 >
8 > to see if any running binaries are linking to old libraries that were
9 > just updated and then I manually restart them. This is particularly
10 > important if the update addresses some security issue in the library.
11 >
12 > Debian and its derivatives take the drastic step of restarting the
13 > daemons for you, which is, in my opinion, undesirable. I'd like to be
14 > in control of when I upgrade and when I restart my daemons.
15
16 For some users restarting might be acceptable, I would rather not have
17 to figure out why the DB just went down and can't restart during an
18 update :)
19 And the checks (like preserved-libs) that run after pkg installation can
20 take so much time that I'd want them to be user-controllable - sometimes
21 you just don't want to wait 5 minutes after a package merge to regain
22 control of your shell
23
24 So I think there are three cases we need to consider:
25 1) autorestart. FEATURES-controlled maybe?
26 2) indicator - warn, but do not take any action
27 3) completely disabled, "don't waste my time"
28 >
29 > OpenSuse has a nice solution. After an upgrade, it tells you that there
30 > are some running binaries still linking against the old libraries and
31 > asks you to run "zypper ps" to see them in a pretty format. You can
32 > then restart at your discretion.
33 >
34 > I'm wondering if we should add something like that? Something to be run
35 > post_inst() and just ewarn the user. It could be a small eclass on its
36 > own that maintainers can elect to inherit and use in ebuilds for daemons.
37
38 eclass sounds hackish since it's portage doing the work. A postinst hook
39 or a direct portage feature sounds more reasonable to me.
40
41 > What do you think? If its a good idea, is implementing it in an eclass
42 > the way to go?
43 Yes, no :)
44
45 Have fun,
46
47 Patrick