[systemd-devel] Fwd: Re: [opensuse-packaging] Fwd: [RFC] Preset Files

[Lennart Poettering]

On Mon, 11.07.11 17:22, Andreas Jaeger (aj at suse.com) wrote:

> on Freitag, 8. Juli 2011, Robert Schweikert wrote:
> > OK, did not know that and was not part of the original message.
> > Well,  using numbers works, still leaves one parsing all files for a
> > specific service and then figuring out which one is processed last
> > and wins. Allowing only one file or enable/disable pair of files
> > makes that task a lot easier.
>
> There is another way that can even avoid reading file contents ;-)
>
> I propose to use two subdirectories "enabled" and "disabled", and then
> just put empty files there, with filename = service name.
>
> In other words: "touch disabled/cupsd.service" would mean cupsd is
> disabled by default, and "touch enabled/sshd.service" would enable sshd
> by default.
>
> The default behaviour (if there is no service-specific default set)
> could also stored with this method - just "touch enabled/DEFAULT".
>
> Advantages of this method:
> - you know exactly which files you have to check for a service - just
>   check for disabled/$service_name and enabled/$service_name.
> - getting a full list for all services should be fast because you only
>   have to read the content of two directories, not any file content.
> - easy to handle in packaging
> - you'll never have any problems with invalid syntax inside the config
>   files ;-))
> - you'll never get headache with file ordering

Interesting idea.

After some discussions Kay and I are not convinced for a number of
reasons: we want the preset lists to be mostly static, i.e. emphasize
that they are not dynamic, but if you split things up you do so to make
partial changes easy. we don't want to use the word "enable" and
"disable" in clearly visible areas in order not to confuse things
further. It's not pretty if we ship tons of zero length flag files in
RPMs. And most importantly, with the list files you can have an easy way
how you override them via and overlay file in /etc, and symlinks to
/dev/null (whcih is how the rest of the systemd functionality handles
this, and udev too). This is not so easy with individual flag files,
since you cannot disable both the enable and the disable flag file with
one construct (unless you introduce a third dir). Also, it's probably
slower, since file systems tend to be optimized for reading linear files
rather than sets of individual files. In fact, systemd by its unit files
already uses quite a number of small files and we should do the best to
avoid that we even double that. Then, it would be a bit confusing if
there's both a file "avahi-daemon.service" and another file
"avahi-daemon.service". One of it empty and a flag file, and the other
with actual contents, and they have completely different semantics based
on the dir the are in. Finally, the text files stuff is a bit more
flexible in case we want to extend this to add "mask" as another option,
on top of "enable" and "disable".

> The only thing my proposal doesn't solve is if enabled or disabled
> should win if both exist - but this issue exists in all proposals I've
> seen until now. It's probably something that should be (or already is)
> hardcoded in systemd.

Well, the preset files we proposed have an order, the touch files don't
really. Figuring out what overrides what is easy if you have an order.

Lennart

--
Lennart Poettering - Red Hat, Inc.