On Sat, May 25, 2013 at 10:42:09PM +0800, Thomas Goirand wrote: > On 05/23/2013 03:14 PM, Helmut Grohne wrote: > > I partly disagree here. A good reason to reimplement part of systemd is > > to have a portable subset of its functionality. This could be part of > > the answer to the question of what to do about kfreebsd. > > If I'm not mistaking, the design you are describing is called OpenRC! :)
If that is the way to go, so be it. Just be aware that OpenRC adds yet another incompatible interface to init systems. <rant> I find it depressing to see four init/rc systems, of which three are mutually incompatible in every single possible aspect. Dependency annotation: * sysv: LSB headers * openrc: a shell function * systemd: ini-file / not needed due to socket activation * upstart: another syntax Socket activation: * sysv: inetd can pass one accepting socket as stdin * openrc: no clue * systemd: sockets passed as fd 3 and higher + environment variables LISTEN_FDS and LISTEN_PID * upstart: socket passed as fd specified in environment variable UPSTART_FDS Daemon startup signalling: * sysv: shell script flexibility^Whell * openrc: no clue, guess like sysv * systemd: signalling via dbus, systemd-specific notification mechanism or just assume it to be ready * upstart: tracking via ptrace, tell number of expected forks ahead Resource limits: * sysv: shell has ulimit * openrc: I guess like sysv * systemd: declarative, ini-file * upstart: declarative syntax How is anyone supposed to write a service that runs with all of them? Disabling service: * sysv: /etc/default/$service is frowned upon, update-rc.d $service disable (or chkconfig if you are on redhat) * openrc: rc-update something * systemd: "three levels of off", systemctl disable $service.service, but this gets more complex with lsb init script compatibility * upstart: echo manual > /etc/init/$service.override Some remote resemblance of uniformity in interface might help as well. </rant> Some of these differences are rooted in technical differences (especially the signalling). It would still help a lot if interfaces were less of a surface for differentiation than implementation. Given the above I do not believe supporting even two of the above in a native way (i.e. without lsb compatibility) is possible for a distribution like Debian. Is there any chance in pushing upstreams to consolidate interfaces in any way to make this easier? Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130526202925.ga1...@alf.mars