On Thu, 9 Aug 2012 22:27:37 +0200 Peter Stuge <pe...@stuge.se> wrote:
> Rich Freeman wrote: > > Systemd is a bit more like a shepherd, looking after things for > > their entire lifecycle. > > This is a big part of why it is so useful. > > I threw out init scripts because it was retarded to not monitor > long-running processes on servers. > > Those processes shouldn't fail, but sometimes they do anyway. > > sysvinit does the monitoring already and I wanted to write my own > monitoring solution sometime in the 90s, until I found daemontools > which did exactly what I wanted to do, and in a way quite similar > to how I would have implemented it. Win. \o/ I still remember using djbdns for a while. I especially threw away the daemontools part of it and wrote openrc scripts to not have 20 additional processes to run a tiny DNS server. > > Systemd isn't a like-for-like replacement for traditional inits. > > It aims to be much more, so this is a bit of an apples-to-oranges > > comparison. > > Yes, it is much more, which is a very nice thing on the systems > it supports. I believe systemd is not usuable at all outside Linux > and will not likely ever be, so for prefix there will anyway always > be systemd alternatives in Gentoo! And on those systems the service > files should never be installed. Considering that systemd unit files are sometimes shipped with upstream packages, and often they are practically equivalent to openrc init scripts, I'd rather see openrc supporting that file format as an extension and using it instead of duplicating the same thing in init.d scripts. And yes, that means that people masking service files shoot themselves in the foot. Also, if I had more time (or support), I'd probably start working on a systemd-compatible init system with a more portable design. > > Again, I'm not sure that it HAS to work the way it does > > I would say that it does, because it is required in order to > accomplish what systemd wants to deliver. Not necessarily. You can move many 'extra' systemd features outside of PID 1. For example, unit dependency trees are complex by definition and practically not necessary for PID 1. In other words, it could be designed to move more complex (and thus risky) tasks outside of PID 1. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
