On Mon, 11.07.11 17:22, Andreas Jaeger ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
