Bug 65255

Summary: some units can be started when the file is just copied into .wants/
Product: systemd Reporter: Shridhar Daithankar <ghodechhap>
Component: generalAssignee: systemd-bugs
Status: RESOLVED FIXED QA Contact: systemd-bugs
Severity: normal    
Priority: medium CC: zbyszek
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Shridhar Daithankar 2013-06-02 05:37:21 UTC
If the unit file name contains multiple . characters such as webproxy.container.service, systemctl cannot use it.

If the unit file is renamed such that it contains only one '.' character(e.g. webproxy_container.sevice), systemctl can handle it.

Following is the defect reproduction on archlinux x86_64 with systemd 204.


[root@bheem shridhar]# cd /etc/systemd/system/multi-user.target.wants/

[root@bheem multi-user.target.wants]# cat webproxy_container.service 
[Unit]
Description=Container webproxy service

[Service]
Type=forking
ExecStart=/usr/bin/lxc-start -d -n webproxy
ExecStop=/usr/bin/lxc-stop -n webproxy
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[root@bheem multi-user.target.wants]# systemctl start webproxy_container

[root@bheem multi-user.target.wants]# lxc-info -n webproxy
state:   RUNNING
pid:      2579

[root@bheem multi-user.target.wants]# systemctl stop webproxy_container

[root@bheem multi-user.target.wants]# lxc-info -n webproxy
state:   STOPPED
pid:        -1

[root@bheem multi-user.target.wants]# cp webproxy_container.service webproxy.container.service 

[root@bheem multi-user.target.wants]# systemctl start webproxy.container
Failed to issue method call: Unit webproxy.container.service failed to load: No such file or directory. See system logs and 'systemctl status webproxy.container.service' for details.

[root@bheem multi-user.target.wants]# pacman -Qs systemd
local/initscripts 2012.10.1-1
    System initialization/bootup scripts
local/netctl 1.1-1 (base)
    Profile based systemd network management
local/systemd 204-2
    system and service manager
local/systemd-arch-units 20120915-2
    Arch specific Systemd unit files
local/systemd-sysvcompat 204-2 (base)                                                                                                                                  
    sysvinit compat for systemd
Comment 1 Zbigniew Jedrzejewski-Szmek 2013-06-03 18:14:33 UTC
Hi, the .wants directory is for symlinks which point to real unit files. After the commands shown in your transcript, you have a link webproxy.container.service → .../webproxy_container.service. After you issue the start command, systemd starts looking for webproxy.container.service unit file, and fails, hence the "No such file or directory result". Simply rename the original unit file and all symlinks, and everything should work.
Comment 2 Shridhar Daithankar 2013-06-04 17:33:02 UTC
Umm.. no.. the commands that I have pasted, create two identical(except the name, of course) unit files in /etc/systemd/system/ulti-user.target.wants.

One of them works, one of them doesn't. Thats the bug.

There are no symlinks used in the defect reproduction. Both of them are real file, directly created in /etc/systemd/system/ulti-user.target.wants.
Comment 3 Zbigniew Jedrzejewski-Szmek 2013-06-04 17:52:41 UTC
(In reply to comment #2)
> Umm.. no.. the commands that I have pasted, create two identical(except the
> name, of course) unit files in /etc/systemd/system/ulti-user.target.wants.
Oh, it wasn't clear from the transcript, because 'cat' doesn't differentiate
between a file and a symlink.

> One of them works, one of them doesn't. Thats the bug.
OK, that we be something different indeed.

> There are no symlinks used in the defect reproduction. Both of them are real
> file, directly created in /etc/systemd/system/ulti-user.target.wants.
OK, just to verify: what does 'ls -l /etc/systemd/system/multi-user.target.wants' say?
Comment 4 Shridhar Daithankar 2013-06-05 03:46:10 UTC
Oh sorry, I should have reported ls -la finding earlier. my bad..

# ls -al *container*
-rw-r--r-- 1 root root 211 May 25 20:22 webproxy_container.service
-rw-r--r-- 1 root root 211 Jun  5 09:18 webproxy.container.service

[root@bheem multi-user.target.wants]# pwd
/etc/systemd/system/multi-user.target.wants

[root@bheem multi-user.target.wants]# systemctl start webproxy.container
Failed to issue method call: Unit webproxy.container.service failed to load: No such file or directory. See system logs and 'systemctl status webproxy.container.service' for details.

[root@bheem multi-user.target.wants]# systemctl start webproxy_container

[root@bheem multi-user.target.wants]# lxc-info -n webproxy
state:   RUNNING
pid:      1337

[root@bheem multi-user.target.wants]# diff webproxy_container.service webproxy.container.service

No difference is reported i.e. the files are identical.

Thanks
Comment 5 Zbigniew Jedrzejewski-Szmek 2013-06-05 04:22:29 UTC
OK, that indeed seems like a bug. But the bug is that *any*
unit that is just in .wants/ is started, not that the one
with dots in the name is *not* started.
Comment 6 Zbigniew Jedrzejewski-Szmek 2013-06-05 04:25:58 UTC
(In reply to comment #5)
> OK, that indeed seems like a bug. But the bug is that *any*
> unit that is just in .wants/ is started, not that the one
> with dots in the name is *not* started.
To elaborate on that: the .wants/ directory is not in the standard
search path for units, and systemd should not load the unit file
from there, because later on it will not be able to find it.
At least that's the way I understand how things should work...
Unfortunately the whole unit-searching/unit-loading mechanism
is not fully defined, and quite a few corner cases behave in
unexpected ways.
Comment 7 Zbigniew Jedrzejewski-Szmek 2017-09-22 08:41:31 UTC
Finally fixed in https://github.com/systemd/systemd/commit/9577878210.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.