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

[林自均]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180527/22a682cf/attachment.html>