Hey Tom, Tom Gundersen [2014-11-18 14:10 +0100]: > This I think should be considered a bug in the unit file. If a unit > has a /usr/lib symlink, then it is statically enabled (i.e., > 'enable'/'disable' has no effect), so it should not install symlinks > in /etc, and hence not have an [Install] section. At least with the > current semantics.
Note that these were all just experiments. We just moved a wants.d/ link from /etc/ to /lib and checked the current behaviour. > > - Wrt. the "golden image, /etc reset" approach of reducing base os > > installation defaults in /etc, this is another instance of "always needs to > > be there" clutter in /etc. If the package default is to start the service, > > then it's better to just ship that wants.d/ symlink in the package (and thus > > in /usr) instead of always having to create the symlink in /etc at package > > install time or after a factory reset. > > I get where you are coming from, but presets will give you the same result, > no? By and large yes. Slightly different mechanics, but same eventual result in /etc/. The reason for this thread is whether we can get "better", not "same" :-) > > - We are mixing sys admin information and distro default choices in the same > > directories, and can't tell apart what is what. > > That is true. Could we perhaps improve on systemctl by printing > "enabled (preset)"/"disable (preset)" for units that are in the > default state? I know this does not change the fact that you have > distro-default (via presets) links in /etc, but it should give the > end-user a nicer experienc I guess? It would at least make it easier for an admin to see what he actually did change, even though it's looking at systemctl output instead of just looking at /etc/. > So you are essentially proposing to replace the preset concept? I don't know, maybe. I see how for some use cases, embedded devices, custom images etc. presets make sense. But for a large general distro, any preset other than "enable *" or "disable *" seems unwieldy to mee, as you don't want to maintain a static list of units anywhere. > 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'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). > unpreset (or something like that) - [Install] section and symlink in > /usr/lib/**/*.wants.d/ and an overriding symlink in /etc pointing at > /dev/null IMHO this should also just be "disabled" -- /etc/ just overrides /usr/ here. /dev/null symlink is an obvious way to express that; another would be to put a 0-byte .service file into /etc/systemd/system/ so that the enabled unit would be a no-op. Perhaps there are different ways even -- as long as we can clearly express "we want to override the /usr/lib/**/wants.d/foo.service enablement". > Doing 'enable' on a preset unit will then just delete the symlink to > /dev/null from /etc (if it exists) and doing 'disable' will add it. > This would also entail changing the current logic to check the target > of /**/*.wants.d/ symlinks to see if they point to /dev/null, in which > case they should be ignored. > > Did I understand that correctly? Right. (with the aforementioned variability in the implementation). I think the admin systemctl enable/disable interface is just fine, and I see no need to introduce yet another concept/API/interface. > > - If we ln -s /dev/null /etc/<…>/<…>.wants/<unit>, then systemctl status > > <unit> will display the unit as being enabled, and it will activated once > > the target is reached. This is also counterintuitive, as usually this means > > to mask/completely disable the unit. > > You cannot mask an wants.d/* symlink, only the unit itself, so this is > actually not defined. My understanding is that this is a concept you > would like to introduce rather than a bug. Correct. It's the obvious thing that came to my mind, as (as you say) the current semantics of that is undefined, and we use /dev/null symlinks for masking already. > > Part of the discussion on #systemd pointed out that the admin should then > > use systemctl mask <unit>. However, that means: > > - The admin can't retarget a default installed unit without recreating > > another unit file > > Correct. But is that something we want? I mean, how I would retarget a > unit file is to make a copy, edit the [Install] section and then > "systemctl enable" it. I guess we should not encourage admins to go > fiddling with the symlinks manually? I'm leaving that to Didier, I'm not entirely sure what he meant with this. But I think this was just a followup on IRC where the current implementation was discussed, i. e. as an alternative way around "systemctl disable for an existing wants.d symlink in /usr doesn't work". > > - There are 2 commands to "disable" an unit: mask for some, disable for > > others, this can bring confusion and admins won't know the semantic > > difference between the two (and indeed this is rather technical and > > unintuitive) > > Well, the meaning we have been using so far is that statically enabled > units are things that does not really make sense to disable (which is > different from it being enabled by default), and for all other units > the way to enable/disable them (be it by default or manually) is by > installing symlinks in /etc. Right, that's how I understood it as well. I. e. an admin would rarely go and mask an unit, unless she really knows what she's doing. OTOH it's perfectly reasonable to disable an unit like apache. > > - The status reported with systemctl is still disabled when it's not. > > We can probably improve on that. I guess no one really explored the > case of static units with [Install] sections. I think they should not be considered static; they are merely "enabled by default" in the package, as the wants symlink happens to be in /usr instead of /etc, but other than that they should be exactly the same. > My take on this is: make sure presets are applied on "firstboot" > (which I think they are), so empty /etc works just fine, and then > improve on systemctl to better show the distinction between 'enabled > by default' or 'enabled by choice' (and same for 'disabled'). I guess if the full idea of not requiring the symlinks in /etc in the first place is rejected, then that would be the next best thing. Thanks! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
