SysVinit to Systemd cheatsheet change.. can someone verify it's right?

Lennart Poettering mzerqung at
Thu Feb 24 13:23:06 UTC 2011

On Wed, 23.02.11 17:38, Toshio Kuratomi (a.badger at wrote:

> I just made a couple changes to the first table of this page:
> The chkconfig frozbozz --levels 345 on line listed systemctl enable
> frozbozz.service as the main equivalent.  From running that command on
> rawhide, that doesn't seem to be correct.  enable made the service active in
> the targets that were listed in the services unit file (in the WantedBy=
> line).  It didn't have anything to do with the runlevels that the system
> administrator was specifying (345).

Uh. This should be dropped entirely. In systemd the classic SysV
runlevels exists only as compatibility aliases and they do have
different semantics: unless you go and reconfigure things non-trivially
runlevel 5 ( will always be a superset of runlevel 3
( And runlevel 2 and runlevel 4 will always be
synonyms of 3. Hence it makes little sense to enable something in
runlevel "3 and 4", since that will actually just enable it in and that's it. 

On top of that one shouldn't limit ones focus to the equivalents of
runlevels. In systemd things are a lot more flexible. For example
instead of hooking yourself into "" you could hook your
stuff into "" which is activated as soon as bt hw is
around. bluez is now activated like this. 

I don't think runlevels should appear on the cheat sheet here.

> The second change is that the "manual" method specified there was  using
>   ln -s ../frobozz.service /lib/systemd/system/
> This seems to be incorrect since it's touching /lib instead of /etc.  /etc
> would both be the proper FHS place to do this (/lib and /etc could be on
> separate partitions with different read-write permissions in FHS and /etc
> might be backed up while /lib would not by a sysadmin that thinks the system
> adheres to the FHS) and it seems to be where the systemctl enable command
> puts the symlinks as well.

Yes, as mentioned elsewhere, in systemd /etc/systemd/system is admin
territory, and /lib/systemd/system is packager territory. The former
always overrides the latter. If and admin wants to edit a service file he
should copy it from /lib/systemd/system to /etc/systemd/system and edit
it there. Then the package manager will never muck with it. Similarly,
.wants/ links should be placed in /etc, too.


Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list