The road forward for systemd
The road forward for systemd
Posted May 26, 2010 17:11 UTC (Wed) by alogghe (guest, #6661)Parent article: The road forward for systemd
However as most of us are -users- of init systems I'm not sure that shaving a few seconds off the boot that is already getting pretty fast is that attractive (non of my systems reboot very often at all) for the further disruption of a new init system.
A key feature that would cause me to be interested in a new init system is something I've seen no awareness of in from the groups involved -
Self healing ala Monit http://mmonit.com/monit/
Here's an example from monit of what I'd like to see in an upstart or systemd configuration -
check process sshd with pidfile /var/run/sshd.pid
start program "/etc/init.d/sshd start"
stop program "/etc/init.d/sshd stop"
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout
Monit allowed me to create bulletproof embedded systems to deploy in developing economy banks.
Most daemon issues are not caused by pids just dying in my experience.. it's when they become unresponsive to user/program interactions. None of the init replacements deal with that (including solaris as I recall).
I'd like this integrated in phone/laptop/server environments.
P.S. Lennart thanks for Pulse, it's been an awesome improvement.
Posted May 26, 2010 22:58 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
Posted May 28, 2010 0:29 UTC (Fri)
by gerdesj (subscriber, #5446)
[Link] (1 responses)
I think that the daemon control system itself (whatever it is called) should be as intelligent as possible. If it can know that a daemon is borked and take remedial action, ie restart it sensibly until it is shown to be buggered and then give up, then great.
Even better if you could feed it rules of some sort that told it how to tell the difference between "recalcitrant" and "properly buggered".
Pretty much all systems I know of have a "status" subcommand to the service/daemon controller - why not make it actually work properly to the point where you can rely on it *completely?
Basically, would it not be nice to be able to believe your service manager when it says that Apache is fine rather than reaching for Monit/Nagios/web browser.
If the Gentoo "/etc/init.d/<service> zap" command went away then this problem is solved.
(* => for a given value of completely, which at the moment on all systems I manage (Gentoo, SLES, Fedora, *buntu, Win{lots of different versions} is local knowledge and folklore)
Posted May 28, 2010 5:27 UTC (Fri)
by jrn (subscriber, #64214)
[Link]
Posted Jun 5, 2010 13:29 UTC (Sat)
by segedunum (guest, #60948)
[Link] (4 responses)
Pffffff. Lennart should fix PulseAudio properly first by solving its extreme latency issues, amongst other things, before faffing about with something else.
PulseAudio is the reason I run a Mac. Seriously.
Posted Jun 7, 2010 11:58 UTC (Mon)
by nye (subscriber, #51576)
[Link] (3 responses)
And the reason I run Windows, in fact.
Posted Jun 7, 2010 13:15 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
The only reason? IMHO this amounts to cutting off one's nose to spite one's face. It is after all quite possible to run Linux on a workstation without PulseAudio. I do, for example (on Debian sid, too), and audio still seems to work for me even so.
Posted Jun 7, 2010 16:23 UTC (Mon)
by nye (subscriber, #51576)
[Link] (1 responses)
Posted Jul 7, 2010 6:06 UTC (Wed)
by Triffid (guest, #68496)
[Link]
Between PA and Avahi, I have had quite a few problems with stuff this guy has written. Systemd looks like another attempt to change things for no good reason.
The road forward for systemd
The road forward for systemd
The road forward for systemd
The road forward for systemd
The road forward for systemd
The road forward for systemd
The road forward for systemd
The road forward for systemd