Re: init system policy
On 21/11/14 17:07, Philip Hands wrote:
> Is there any way this isn't going to be an enormous surprise to people
> that are used to the way that Debian usually treats /etc?
I do get your point; editing the (underlying file for the) .service is
unnecessary and undesirable for systemd, and if you blindly do "vi
/etc/.../thing.service" and don't realise you're following a symlink,
that would be a bad idea.
There are two slightly separate things going on here: the contents of
each unit, and the units that are "wanted" by each "target". If the
units' contents are like /etc/init.d/whatever, then the targets
(multi-user.target and so on) are like runlevels, and the symlinks in
*.target.wants to units that are wanted by each target are like the
symlinks in rc?.d to scripts that are wanted by each runlevel.
For the contents, there are ways to override it that do not involve
editing the shipped file: the preferred way is to add "drop-ins" in
/etc/systemd/system/whatever.service.d/*.conf which can override
individual lines.
You can also copy the file from /lib/systemd/system/whatever.service to
/etc/systemd/system/whatever.service and edit that, which is the closest
equivalent to editing /etc/init.d/whatever in sysvinit.
If I remember correctly, the maintainers of systemd in Debian considered
the idea of moving or copying each file from /lib/systemd/system into
/etc/systemd/system (to make them into dpkg- or ucf-controlled
conffiles), and specifically decided not to do it.
> It seems that you're saying that throwing links in and out of /etc is
> the way one turns things on and off
Normally, manipulating symlinks in /etc/systemd/system/*.target.wants is
sufficient, and preferred. Removing those symlinks is not 100%
equivalent to rc?.d, strictly speaking: it means "starting this during
boot is not required, unless you find some other reason why it should
be". The unit remains in the dependency graph but is excluded from the
set of explicit goals.
The display manager is an exception to the "normally..." because there
is another reason for it to be required: the display-manager.service
alias is "wanted by" graphical.target, using a line in the file rather
than a symlink (because the definition of graphical.target is exactly
"multi-user mode and also start *dm").
The way to not start any display manager under systemd, even if one is
installed, is to make /etc/systemd/system/default.target a symlink to
/lib/systemd/system/multi-user.target, overriding the existing symlink
/lib/systemd/system/default.target -> graphical.target.
> and that to actually disable them one needs to symlink them to /dev/null
A symlink to /dev/null in /etc/systemd/system means "forget you ever
knew about a unit with this name". It "masks" the corresponding file in
/lib/systemd/system and causes it not to be loaded, as if it wasn't
installed at all; anything with a soft dependency on it (Wants) will
carry on without it, and anything with a hard dependency on it
(Requires) will just not start.
> I seem to have achieved the same effect by replacing all the symlinks I
> could find with empty files -- I guess symlinks are preferred because
> you don't need to try to open one that's pointing to /dev/null, is that
> right?
An empty file in /etc/systemd/system also counts as masking the service.
A link to /dev/null is conventional, and I think systemd might have a
minor optimization for it as you say, but the practical effect is the same.
I'm not sure whether a regular file in /etc/systemd/system/*.wants.d/
has well-defined semantics, any more than a regular file in /etc/rc2.d/
would: *.wants.d is documented to contain symlinks to units, as opposed
to units themselves.
S
Reply to: