[Pkg-utopia-maintainers] Bug#527846: Bug#527846: Bug#527846: consolekit: does not provide a init.d script (how do I restart the daemon?)

Francesco Poli frx at firenze.linux.it
Sat May 9 11:32:20 UTC 2009


severity 527846 important
thanks


On Sat, 09 May 2009 02:05:20 +0200 Michael Biebl wrote:

> Francesco Poli wrote:
> > On Sat, 09 May 2009 00:49:31 +0200 Michael Biebl wrote:
[...]
> >> It's not recommended to restart console-kit-daemon anyway, as you will lose all
> >> registered sessions.
> > 
> > Well, but what if a security update on one of the dependencies creates
> > the *need* to restart the daemon?
> > This is the first time I encounter a daemon which I should try to never
> > restart...  :-o
> 
> iirc udev is also not restarted on upgrades,

But udev *may* be manually restarted with

  # /etc/init.d/udev restart

without undesired consequences, AFAICT.

> so is /sbin/init,

I have never found a case where checkrestart suggested me to
restart /sbin/init, I am not even sure if that *could* actually happen.

> or wpasupplicant.

I have zero experience with wireless networks, so I cannot comment on
this, sorry.

> 
> The easiest way is to simply restart the system.

Sorry, but this is simply *unacceptable*, especially for a production
box where more than one user may be using the system, e.g. via SSH.
For instance, think of a scientific computation workstation where users
start long-running number crunching programs.

The *only* case where I can live with the need to reboot the whole
system is when the kernel is updated for security reasons.

> 
> > It sounds kinda strange that I am recommended against restarting a
> > daemon!
> > 
> >> Hope that answers your questions.
> > 
> > It does answer my questions, but it also generates even more
> > head-scratching!  :-/
> 
> Well, you can restart consolekit, but then you will have unexpected behaviour
> (users in the desktop session will no longer be able to
> suspend/hibernate/shutdown etc).

I really think that a daemon that cannot be safely restarted without
unexpected consequences is badly designed.
There *must* be a safe way to restart the daemon without unintended
weird behaviors.
Hence the severity of this bug is at least "important" (if not higher).

I strongly recommend fixing this design flaw.

I don't know exactly how this could be done: maybe there should
be a signal (e.g.: SIGHUP, or even SIGTERM) that forces the daemon to
save its state somewhere on the filesystem (probably somewhere
under /var/lib , if I understand the FHS correctly), so that the state
can be restored as soon as the daemon is started again.

Another strategy could be that the daemon always keeps its state on the
filesystem, and only wipes it out when it has to.  This way, stop/start
cycles for the daemon would not have a strong impact on the system
behavior.

There are probably better solutions...


Please fix this issue, and/or forward the bug report to upstream, as
appropriate.
Thanks in advance.


-- 
 New location for my website! Update your bookmarks!
 http://www.inventati.org/frx
..................................................... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20090509/32e5bbf9/attachment.pgp>


More information about the Pkg-utopia-maintainers mailing list