Keeping notes: This is a well-known property/problem of systemd job
transactions. In its simplest form it looks like this:

# cat /etc/systemd/system/foo.service 
[Unit]
Description=some foo service
Requires=dep.service
After=dep.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/echo foo is running
ExecReload=/bin/echo reloading foo

# cat /etc/systemd/system/dep.service 
[Unit]
Description=dependency of foo.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/bin/sleep 3
ExecStart=/bin/echo dep is running
ExecStartPost=-/bin/systemctl reload foo.service

# systemctl daemon-reload; systemctl start foo.service
→ hangs forever, and systemctl list-jobs shows:

JOB UNIT        TYPE  STATE  
886 dep.service start running
818 foo.service start waiting

In this form it's obviously bogus (nobody would write a unit like this).
But it becomes quite common if the "reload" happens through some
indirection, like a DHCP enter/exit or an ifupdown hook.

For these situations the reload should happen with --no-block, to not
wait until it's finished, but just to enqueue it. While that's easy
enough if a systemd unit itself does that, our various hooks didn't take
that into account when they were written, and as they usually use
"invoke-rc.d" or "service" (both of which don't know about --no-block)
we need a more generic solution/workaround.

I proposed some bits on the upstream ML:
http://lists.freedesktop.org/archives/systemd-
devel/2015-February/027966.html

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1417010

Title:
  systemd init gets stuck reloading smbd.service

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1417010/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to