9:13 a.m.
We've long had a way to restart system services on an RPM upgrade via
condrestart in the initscript. However, there is another kind of service
which runs, services bound to desktop sessions. Rather that global,
these are per user session.
Is there a mechanism by which an RPM which installs a desktop service
can perform the equivalent of a condrestart on the session service?
I imagine such a mechanism would work by iterating over every DBus
session bus, query for the existence of the service, if it exists send
it a stop signal and then after the service leaves the bus perform a
StartServiceByName within the session.
Do we have anything like that? I suspect not. If not then how can a root
process iterate over existing sessions?
--
John Dennis <jdennis(a)redhat.com>
10:44 a.m.
The Mugshot client daemon does this itself by installing a file called
"version" with the package version, and if said file changes it restarts
itself.
The version file doesn't have the RPM release in it, but presumably could.
An advantage of this approach is that it doesn't require magic in the
spec file, though presumably it has downsides too. One downside is that
the restart can be a bit too early (before the upgrade is complete).
Havoc
11:12 a.m.
On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote:
The Mugshot client daemon does this itself by installing a file
called
"version" with the package version, and if said file changes it restarts
itself.
The version file doesn't have the RPM release in it, but presumably could.
An advantage of this approach is that it doesn't require magic in the
spec file, though presumably it has downsides too. One downside is that
the restart can be a bit too early (before the upgrade is complete).
Ah yes, the incomplete upgrade race condition problem. This is precisely
the problem I'm trying to solve. I had done something similar to what
mugshot did except it noticed when a socket was closed and reopened
(result of a restart and the newly opened connection reported a
different version). The package is divided into independent client and
server packages. Client in this case being a desktop session service.
The session service notices the upgrade which yum or rpm just finished
installing and restarted and then decides to restart itself. But opps!
Yum or rpm is now in the middle of updating the code for the desktop
session component and the restart generates errors.
One has to know to restart the desktop session service only after its
files have been upgraded fully, e.g. in %post. Any scheme based on
watching other components will expose you to a race condition.
From this I conclude:
* There must be some mechanism callable in %post to signal the desktop
session service to restart.
-OR-
* One must let the old desktop session service run until the user logs
out and back in again thus restarting it. That might be a very long time
and is clearly counter intuitive to someone who just installed an
upgrade.
Perhaps I've not understood all the issues but it seems to me one is
between a rock and a hard place if one wants to do the right thing
robustly.
--
John Dennis <jdennis(a)redhat.com>
12:07 p.m.
On Fri, 2007-06-15 at 12:12 -0400, John Dennis wrote:
* There must be some mechanism callable in %post to signal the
desktop
session service to restart.
It sounds like the Fedora architecture is moving towards everything
calling yum-updatesd to do work. In that case, it should be fairly
trivial to have yum-updatesd send a D-BUS signal on the system bus when
the entire package set installation is complete.
This would have the advantage that it avoids problems with
interdependent packages being restarted out of sync[1], and you don't
have to mess with horror that is RPM spec files[2] and %post for every
package.
Doing it this way, you then need a nice way to figure out which
applications need to be restarted. One possibility is to standardize
watching on the mtime of the .desktop file the package installs - though
this might interact badly with menu editing, not sure. An alternative
would be that the post-installation system sends out signals with the
Exec= line of every .desktop file it changed, and then apps have to be
modified to catch that signal and restart. Too bad .desktop files don't
have a GUID in them =/
Finally, anyone tackling this problem should also think about the issue
right now with key library packages like gtk+ being updated for security
issues. Say there is a flaw in a pixbuf loader - this potentially
affects all applications and thus requires a logout/login. Have some
way for the system to handle that (this could just be a different signal
that something like puplet catches).
[1] An example is the mugshot client and loudmouth libraries being
upgraded at the same time - it is key that the client gets restarted
using the new loudmouth library.
[2] (unprintable)
12:19 p.m.
Le vendredi 15 juin 2007 à 12:12 -0400, John Dennis a écrit :
One has to know to restart the desktop session service only after
its
files have been upgraded fully, e.g. in %post. Any scheme based on
watching other components will expose you to a race condition.
user starts gnome-terminal
user launches a yum update
first gui package reaches the %post stage
session is restarted
gnome-term is killed
yum is killed in the middle of an upgrade
user system is broken
user is angry
--
Nicolas Mailhot
12:36 p.m.
On Fri, 2007-06-15 at 19:19 +0200, Nicolas Mailhot wrote:
Le vendredi 15 juin 2007 à 12:12 -0400, John Dennis a écrit :
> One has to know to restart the desktop session service only after its
> files have been upgraded fully, e.g. in %post. Any scheme based on
> watching other components will expose you to a race condition.
user starts gnome-terminal
user launches a yum update
first gui package reaches the %post stage
session is restarted
gnome-term is killed
yum is killed in the middle of an upgrade
user system is broken
user is angry
No, we are not discussing restarting the entire desktop session, that
would be a huge problem. We are talking about restarting specific
session *services*.
--
John Dennis <jdennis(a)redhat.com>
2:57 p.m.
On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote:
The Mugshot client daemon does this itself by installing a file
called
"version" with the package version, and if said file changes it restarts
itself.
The version file doesn't have the RPM release in it, but presumably could.
An advantage of this approach is that it doesn't require magic in the
spec file, though presumably it has downsides too. One downside is that
the restart can be a bit too early (before the upgrade is complete).
We changed a while ago so Mugshot no longer installs the version file as
a normal file .. instead it's %ghost and the end of the %post does:
echo %{version} > %{_datadir}/mugshot/version
Now, there are still a downside: you have to wake up to check for an
upgrade every so often. If you wake up too often, you drain power.
If you wake up less often, it might be a while before you switch
versions, so the desktop component needs to be robust against that.
(Doesn't try to read a file that gets removed in the newer version, say)
For Mugshot, we know when we've told the user to go get a new version,
so we check more frequently for a while after that.
- Owen
3:57 p.m.
Hi,
echo %{version} > %{_datadir}/mugshot/version
Now, there are still a downside: you have to wake up to check for an
upgrade every so often. If you wake up too often, you drain power.
If you wake up less often, it might be a while before you switch
versions, so the desktop component needs to be robust against that.
Why aren't you just watching the file with inotify or gamin or whatever?
--Ray
6:56 a.m.
On Fri, 2007-06-15 at 16:57 -0400, Ray Strode wrote:
Hi,
> echo %{version} > %{_datadir}/mugshot/version
>
> Now, there are still a downside: you have to wake up to check for an
> upgrade every so often. If you wake up too often, you drain power.
> If you wake up less often, it might be a while before you switch
> versions, so the desktop component needs to be robust against that.
Why aren't you just watching the file with inotify or gamin or whatever?
^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think that sort of answers the question :-)
- Owen
4:23 p.m.
Owen Taylor wrote:
On Fri, 2007-06-15 at 11:44 -0400, Havoc Pennington wrote:
> The Mugshot client daemon does this itself by installing a file called
> "version" with the package version, and if said file changes it restarts
> itself.
>
> The version file doesn't have the RPM release in it, but presumably could.
>
> An advantage of this approach is that it doesn't require magic in the
> spec file, though presumably it has downsides too. One downside is that
> the restart can be a bit too early (before the upgrade is complete).
We changed a while ago so Mugshot no longer installs the version file as
a normal file .. instead it's %ghost and the end of the %post does:
echo %{version} > %{_datadir}/mugshot/version
Now, there are still a downside: you have to wake up to check for an
upgrade every so often. If you wake up too often, you drain power.
If you wake up less often, it might be a while before you switch
versions, so the desktop component needs to be robust against that.
(Doesn't try to read a file that gets removed in the newer version, say)
For Mugshot, we know when we've told the user to go get a new version,
so we check more frequently for a while after that.
I have actually been wanting to do this for Firefox, as the
/usr/lib/firefox-x.y directory changes. I've pondered having the
%postun script check to check $1 == 1 or something to see if it was an
upgrade, and if so call dbus-send to firefox on the system bus (which
firefox would listen to) to load a webpage telling the user they need to
restart the browser.
10:54 a.m.
John Dennis wrote:
We've long had a way to restart system services on an RPM upgrade
via
condrestart in the initscript. However, there is another kind of service
which runs, services bound to desktop sessions. Rather that global,
these are per user session.
Is there a mechanism by which an RPM which installs a desktop service
can perform the equivalent of a condrestart on the session service?
I imagine such a mechanism would work by iterating over every DBus
session bus, query for the existence of the service, if it exists send
it a stop signal and then after the service leaves the bus perform a
StartServiceByName within the session.
Do we have anything like that? I suspect not. If not then how can a root
process iterate over existing sessions?
The SELinux avc monitoring tool, sealert does simply restarts the app
and setroubleshoot service. Might want to see how it handles that.
11:18 a.m.
On Fri, 2007-06-15 at 11:54 -0400, Christopher Aillon wrote:
The SELinux avc monitoring tool, sealert does simply restarts the app
and setroubleshoot service. Might want to see how it handles that.
:-) :-) :-)
Yup, that would be my code and what prompted the question. The mechanism
seems to be susceptible to a race where sealert restarts itself before
all of its files have been upgraded.
--
John Dennis <jdennis(a)redhat.com>
11:15 a.m.
John Dennis wrote:
On Fri, 2007-06-15 at 11:54 -0400, Christopher Aillon wrote:
> The SELinux avc monitoring tool, sealert does simply restarts the app
> and setroubleshoot service. Might want to see how it handles that.
:-) :-) :-)
Yup, that would be my code and what prompted the question. The mechanism
seems to be susceptible to a race where sealert restarts itself before
all of its files have been upgraded.
Ah :-)
6152
days inactive
6153
days old
desktop@lists.fedoraproject.org
12 comments
7 participants
participants (7)
-
Christopher Aillon -
Colin Walters -
Havoc Pennington -
John Dennis -
Nicolas Mailhot -
Owen Taylor -
Ray Strode