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 林自均 <johnl...@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.gallag...@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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
