Restarting desktop session services on RPM upgrade?

John Dennis jdennis at redhat.com
Fri Jun 15 16:12:36 UTC 2007


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 at redhat.com>




More information about the Fedora-maintainers mailing list