On 15.10.2012 17:33, Lennart Poettering wrote: > 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
Would it be possible to detect such dead lock situations and simply refuse new requests which would cause a dead lock? This would make systemd more robust overall. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
