Systemd sysv compat mode, was: Re: guidelines for upstart in oe?

[Koen Kooi <koen@dominion.thruhere.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 19-09-11 10:06, Anders Darander schreef:
> * Steffen Sledz <sledz@dresearch-fe.de> [110916 18:15]:
>> I'm not sure if there exist upstart based oe distros/images. But it 
>> seems that there are some systemd based ones 
>> (recipes/images/angstrom-systemd-image.bb).
> 
>> Do they have a similar problem? How do these handle the sysvinit config
>> vs. systemd config for the different services?
> 
> It varies slightly.
> 
> Some packages, e.g. dropbear, has an extra package dropbear-systemd in 
> meta-oe, that packages the systemd unit files for dropbear. The same is 
> true for dbus in oe-core.
> 
> Other packages, like ofono in oe-core, pacakages the systemd unit files 
> directly in the ofono-package.
> 
> In all these cases, sysvinit files are supplied directly in the main 
> package.

This works for systemd since it has a working sysv compat mode and override
mechanism. Consider the following scenarios:

a) native mode
/lib/systemd/system/foo.service

native systemd unit will get used

b) dual mode
/etc/init.d/foo
/lib/systemd/system/foo.service

native systemd unit will get used, sysv script gets ignored.

c) sysv mode
/lib/systemd/system/foo.service

sysv script will run

d) masking
/etc/init.d/foo
/lib/systemd/system/foo.service is a symlink to /dev/null

sysv script will not run

So in the systemd world we can control which system gets used quite well.
And coming from an OE world writing systemd units is easy since they are
conceptually the same as recipes (e.g. DEPENDS -> Requires:) and don't
require a ton of boilerplate.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOdweBMkyGM64RGpERAuuAAKCzWKuX6zVciC6VGoFv/udJlAgEmQCfRwx9
JDOJJKugRiyamOx+S9RJthg=
=bEGV
-----END PGP SIGNATURE-----