Bug 86748 - systemctl restart does not return for target
Summary: systemctl restart does not return for target
Status: RESOLVED WONTFIX
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-26 17:47 UTC by Oleg
Modified: 2018-03-09 08:00 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Oleg 2014-11-26 17:47:33 UTC
Hi,

Described behaviour is reproduced for systemd-208(RHEL), systemd-215 and trunk(calculate linux).
However, I'm not sure if it is actually a bug, or just misconfiguration of services.
STR:
1) Create following unit files:
$ cat env@.target 
[Unit]
Description=Test Environment Target

[Install]
WantedBy=multi-user.target
$ cat serv@.service 
[Unit]
Description=Service which is part of environment
Requires=env@%i.target

[Service]
PIDFile=/root/test.pid
Type=forking
ExecStart=/usr/bin/python /root/test_service.py
Restart=on-failure
RestartSec=30
TimeoutStopSec=30
KillMode=process

[Install]
WantedBy=multi-user.target
WantedBy=env@%i.target

test_service.py is simple script, which emulates either a fine working daemon, or a daemon which fails to start:
$ cat /root/test_service.py 
#!/usr/bin/env python
import os
from time import sleep
if os.fork() != 0:
    os._exit(0)
os.setsid()
if os.fork() != 0:
    os._exit(0)
os.chdir('/')
## os._exit(2) ## uncomment to emulate failing daemon
pid_fo = open('/root/test.pid', 'w')
pid_fo.write(str(os.getpid()) + '\n')
pid_fo.close()
sleep(3600)

2) Enable target and service and start them:
systemctl enable serv@1.2.3.4
systemctl enable env@1.2.3.4.target
systemctl start env@1.2.3.4.target serv@1.2.3.4

3) Uncomment "os._exit(2)" and restart env@1.2.3.4.target:
time systemctl restart env@1.2.3.4.target

Expected result:
restart command should fail, as "systemctl restart serv@1.2.3.4" fails:
# systemctl restart serv@1.2.3.4
Job for serv@1.2.3.4.service failed. See "systemctl status serv@1.2.3.4.service" and "journalctl -xe" for details.

Actual result:
systemctl does not return:
# time systemctl restart env@1.2.3.4.target 
^C
real	16m0.964s
user	0m0.010s
sys	0m0.000s

Backtrace for systemd-208 systemctl:
#0  0x00007f3766cdeec0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f3767ab7780 in socket_do_iteration () from /lib64/libdbus-1.so.3
#2  0x00007f3767ab65ff in _dbus_transport_do_iteration () from /lib64/libdbus-1.so.3
#3  0x00007f3767a9fd7c in _dbus_connection_do_iteration_unlocked () from /lib64/libdbus-1.so.3
#4  0x00007f3767aa2112 in _dbus_connection_read_write_dispatch () from /lib64/libdbus-1.so.3
#5  0x00007f3768112029 in start_unit ()
#6  0x00007f3768108ac5 in main ()

If serv@.service unit file is created without "Requires=env@%i.target", everything works just fine.
Comment 1 Lennart Poettering 2014-12-08 23:18:56 UTC
WHat does "systemctl list-jobs" show when this hangs?
Comment 2 Oleg 2014-12-09 13:18:17 UTC
calculate ~ # systemctl list-jobs
 JOB UNIT                 TYPE  STATE  
  64 env@1.2.3.4.target   start waiting
   1 graphical.target     start waiting
   2 multi-user.target    start waiting
2792 serv@1.2.3.4.service start waiting

4 jobs listed.
Comment 3 Zbigniew Jedrzejewski-Szmek 2018-03-09 08:00:44 UTC
Closing all stale bugs with NEEDINFO. Please open a new bug at https://github.com/systemd/issues if the problem still occurs.


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.