Re: systemd .service file conversion
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
Reply to: