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 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
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.
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)
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
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*.
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
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
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
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.
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.
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 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 :-)
desktop@lists.fedoraproject.org