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
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.
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.
(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?
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
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.
(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.
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.