[Install] section of symlinked unit file ignored if drop-in file is used

[john.gallagher@xxxxxxxxxxx (John Gallagher)]

I'm using v237, so that makes sense. Thanks for looking into this!

-John

On Sun, May 27, 2018 at 6:50 AM, æ??è?ªå?? <johnlinp at gmail.com> wrote:
> Hi John,
>
> I can reproduced your problem on systemd v236 to v238, but not v235. I think
> it's because from v236 to v238 contains the commit in
> https://github.com/systemd/systemd/pull/7158. However, it seems that the
> commit "d04a93864d" in the git repo fixes the issue. Therefore, you can
> expect that the next systemd version (v239) won't have the issue then.
>
> John Lin
>
> æ??è?ªå?? <johnlinp at gmail.com> æ?¼ 2018å¹´5æ??23æ?¥ é?±ä¸? ä¸?å??10:32寫é??ï¼?
>>
>> Hi John,
>>
>> I'm not sure whether this issue is because of
>> https://github.com/systemd/systemd/pull/7158 or not. I will figure it out.
>> Thanks.
>>
>> John Lin
>>
>> John Gallagher <john.gallagher at delphix.com> æ?¼ 2018å¹´5æ??24æ?¥ é?±å?? ä¸?å??8:07寫é??ï¼?
>>>
>>> If I have a unit file for a service that lives off the unit file
>>> search path, I can link it, and then enable it using the service name
>>> instead of the full path of the unit file:
>>>
>>> $ cat foo.service
>>> [Service]
>>> Type=simple
>>> ExecStart=/bin/sleep 100000000
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>> $ sudo systemctl link ~/foo.service
>>> Created symlink /etc/systemd/system/foo.service â??
>>> /export/home/delphix/foo.service.
>>> $ sudo systemctl enable foo
>>> Created symlink
>>> /etc/systemd/system/multi-user.target.wants/foo.service â??
>>> /export/home/delphix/foo.service.
>>>
>>> If I add a drop-in file for the service though, enabling the service
>>> using the service name does not behave the same way:
>>>
>>> $ cat /etc/systemd/system/foo.service.d/env.conf
>>> [Service]
>>> Environment=FOO=bar
>>> $ sudo systemctl enable foo
>>> The unit files have no installation config (WantedBy, RequiredBy, Also,
>>> Alias
>>> settings in the [Install] section, and DefaultInstance for template
>>> units).
>>> This means they are not meant to be enabled using systemctl.
>>> Possible reasons for having this kind of units are:
>>> 1) A unit may be statically enabled by being symlinked from another
>>> unit's
>>>    .wants/ or .requires/ directory.
>>> 2) A unit's purpose may be to act as a helper for some other unit which
>>> has
>>>    a requirement dependency on it.
>>> 3) A unit may be started when needed via activation (socket, path, timer,
>>>    D-Bus, udev, scripted systemctl call, ...).
>>> 4) In case of template units, the unit is meant to be enabled with some
>>>    instance name specified.
>>>
>>> I get the warning above, and the expected link in
>>> /etc/systemd/system/multi-user.target.wants/ is not created. I can
>>> work around this behavior by doing the enable using the path of the
>>> unit file:
>>>
>>> $ sudo systemctl enable ~/foo.service
>>> Created symlink
>>> /etc/systemd/system/multi-user.target.wants/foo.service â??
>>> /export/home/delphix/foo.service.
>>>
>>> The [Install] section of the unit file being ignored or respected
>>> based on the presence or absence of a drop-in file seems inconsistent
>>> to me, but I am fairly new to systemd, so I may be missing something.
>>> Is this behavior expected?
>>>
>>> Thanks,
>>> John
>>> _______________________________________________
>>> systemd-devel mailing list
>>> systemd-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel