[systemd-devel] foo.bar.d directory changes

[Lennart Poettering]

On Sat, 30.03.13 15:02, Curtis Shimamoto (sugar.and.scruffy at gmail.com) wrote:

> Hello systemd people,
> 
> I was migrating my modified service files away from ".install" to the new
> /etc/systemd/system/foo.bar.d/*.conf setup.  Along the way, I hit a bit
> of a snag.
> 
> I have a custom target for when I use the CK kernel, as it is not able to
> run "systemd --user".  So I have a graphical-ck.target.  So simply as an
> initial test before I started making more significant changes, I tried
> modifying rtkit-daemon.service.  Looking at the service file, it was
> "WantedBy=graphical.target" so I decided to try and add
> "WantedBy=graphical-ck.target".  So I made the necessary directory
> rtkit-daemon.service.d and made a creatively named "wantedby.conf".
> 
> It continued to only install to the graphical.target.wants, so it would
> seem that it does not allow for this change to be made in that particular
> way.  Since then, I have confirmed that the system works with all my
> other non-WantedBy modifications, so my system is not borked otherwise.
> 
> On the Arch Linux forums, another user confirmed that this did not work
> on their machine either.  Oh and BTW, I am using the systemd 198 from the
> Arch repositories.
> 
> So just for clarity's sake, this is what I have that will not work:
> 
> $ cat /etc/systemd/system/rtkit-daemon.service.d/wantedby.conf
> [Install]
> WantedBy=graphical-ck.target
> 
> Graphical-ck.target is basically an exact copy of the graphical.target,
> except that it conflicts with the normal graphical.target.
> 
> I guess I should also mention that this functionality works perfectly
> fine with ".include".
> 
> Also, I noticed that systemd-delta does not reflect the changes made by
> /etc/systemd/system/foo.bar.d/*.conf.  Is this an oversight, or a feature
> that has yet to be implemented?  It is not a big deal really. but I just
> thought I would mention it while I am sending this email.

Hmm, so I am not really convinced we want to interpret .d files for
[Install]. I mean, the primary usecase for [Install] is defining
defaults for installing units, but if this is already subject to
customization if we'd allow .d/ drop-ins for that. Or to say this with
different words: we'd never be able to make use of this in an RPM/DEB
postinst script, since the dropins generally wouldn't exist before the
packet is installed, but it would be interpreted only when it is
installed...

So, I am tempted that this is primarily a documentaton + warning thing,
i.e. where we generate nice warnings explaining the situation when
somebody tries this, rather than make it work. Since making it work
would give a promise we cannot really hold.

In your specific usecase it appears to me you just want to create the
symlinks manually? Note that we encourage admins to create symlinks on
their own. It's well supported. People should not assume that symlink
creation is something that only ever should be done via
[Install]. People are welcome to create new targets and then symlink
everything into them at free will, there is no need to involve
"systemctl enable".

or did I miss something?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.