On Sun, 14.10.12 20:06, Michael Biebl (bi...@debian.org) wrote: > > Summary: systemd blocks on networking.service, networking.service’s > > systemctl blocks on systemd → deadlock. > > > As discussed on IRC: I think there is a bit more to that then the above > explanation. > If you run "systemctl reload" on a non-running service, it will *not* > block and simply returns immediately. So this can't explain the problem > above. > > From past discussions with Lennart, I think the problem is, that systemd > tries to minimize unnecessary actions. > > Say during an transaction, a service is started and reloaded. > systemd will try to reorder the service so it can avoid the reload. > I guess in this case this means blocking, until the actual start > happens. And then we indeed get the deadlock. > > As my memory is a bit vague here, I've CCed Lennart, since I don't want > to tell nonsense. Lennart, I hope you can chime in here and shed some > light on this problem.
systemd only orderes queued jobs against each other. And yes if you have a service foobar.service ordered after waldo.service, and waldo.service issues a job for foobar.service and blocks on it, then systemd will honour the ordering and you might deadlock, indeed. There are various fixes thinkable: Most likely there should not be any ordering between the two units, or you could pass --no-block to avoid the problem. There are even hacks available, such as --ignore-dependencies, but I'd really not recommend using those... Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
