[systemd-devel] /usr vs /etc for default distro units enablement

Andrei Borzenkov arvidjaar at gmail.com
Thu Dec 4 23:58:01 PST 2014

В Tue, 2 Dec 2014 01:46:16 +0100
Lennart Poettering <lennart at poettering.net> пишет:

> On Tue, 18.11.14 14:37, Martin Pitt (martin.pitt at ubuntu.com) wrote:
> > > We now have:
> > > 
> > > enabeld - [Install] section and symlink in /etc/**/*.wants.d/
> > > disabled - [Install] section and no symlink in /etc/**/*.wants.d/
> > > static - no [Install] section and symlink in /usr/lib/**/*.wants.d/
> > > masked - symlink from the unit file-name to /dev/null in /etc
> > > 
> > > you want in addition:
> > > 
> > > preset (or something like that) - [Install] section and symlink in
> > > /usr/lib/**/*.wants.d/
> I am not totally opposed to allowing /dev/null symlinks in .wants.d/
> subdirs, and considering them a way to override dependencies. Such a
> "mask a dependency" concept would be OK.
> > I'd call this just "enabled". It follows the same "/etc/ trumps /usr"
> > schema that we have for udev rules, units, etc., i. e. an "enabled"
> > symlink should be allowed to live in /etc, /usr, and maybe even /run
> > (haven't though about whether this really makes sense, but perhaps for
> > full consistency it should be allowed).
> OK, let me get this right. You want an algorithm like this when
> somebody invokes "systemctl enable":
> a) if the unit file contains [Install], execute that, done
> b) if the unit file does not contain [Install], then delete any
>    /dev/null symlinks in /etc/systemd/*.{wants,requires}.d/* of the
>    same name.
> Then, "systemctl disable" should do this in your opinion:
> a) if the unit file contains [Install] remove all symlinks in
>    /etc/systemd/*.{wants,requires}.d/* to it.
> b) if it doesn't, then *add* new symlinks to /dev/null in all
>    .{wants,requires}.d/ directories where symlinks exist for it in
>    /usr?
> Did I get this right?

That's not how I actually understood it. enable/disable still applies
only to units with [Install] section as it is now. Just that

systemctl disable

means that if there are links in /usr/lib, they are masked in /etc.
I.o. unit foo.service is enabled if

1. [Install] section exists
2. Links from [Install] section are present either in /usr/lib or
in /etc

unit foo.service is disabled if

1. [Install] section exists
2. There are no links from [Install] in /usr/lib or /etc *OR* there are
links in /usr/lib which are masked in /etc.

Units without [Install] section remains static as they are today.

This will allow to cleanly separate distribution default (/usr/lib) and
admin decision (/etc). Also this will allow systemctl list-unit-files to
supply information like

enabled (default)/enabled (admin)

depending on whether link in /usr/lib or /etc exists.

IOW - /usr/lib keeps default state and /etc keeps overrides for default

> I am not convinced this is really a good idea though, as with this
> scheme package changes might reenable a unit that is otherwise
> disabled. Also, I kind like the fact that there's currently a clean
> error message generated when people try to disable a unit that is part
> of the OS itself. The scheme you propose would degrade that case to a
> NOP however, right?
> Lennart

More information about the systemd-devel mailing list