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
pgpp1mDBj6Dhm.pgp
Description: PGP signature
