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

Lennart Poettering lennart at poettering.net
Mon Dec 1 16:46:16 PST 2014


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?

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

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list