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
