On 01/08/2018 05:52 PM, Simon McVittie wrote: > Does A.service even need B.service during shutdown if it has not > previously interacted with (=> started) B.service? That's not correct implication, due to concurrency, B.service may be stopped before A.service.
> On Mon, 08 Jan 2018 at 16:53:04 +0100, Jérémy Rosen wrote: >> That means that the only way to fix that without explicitely telling someone >> about the dependency is to allow dbus to start units while its shutdown is >> pending [...] this seems to be explicitely forbidden > > I didn't write that special case, but I agree with it. Starting D-Bus > services while the sword of Damocles is hanging over dbus-daemon's > head does not sound like a route to guaranteed success. As soon as > dbus-daemon gets SIGTERM, they'll find that their D-Bus AF_UNIX socket > is rather less useful than it was a moment ago... Nice explanation. I forgot to mention that A.service already has dependency on dbus.service (which is unnecessary by the elegance criterium). So there's a guarantee two sword will not fall down until A.service terminates. > If A.service can be made to shut down correctly without B.service, > then that seems good in any case. (What happens if B.service crashes?) The A's best effort would make sense in the crash case, however, I don't think it's the right place . > Failing that, if A.service genuinely needs D-Bus during its shutdown, > it probably also makes sense to serialize it After=dbus.service (not > just dbus.socket) so that dbus-daemon will be kept alive until A.service > actually exits. That's actually a valid idea (see above). > To be honest that doesn't seem too bad to me. Yes, the lesser viability of other options I see, the more I like it as well. The alternative of changing the condition from manager_unit_inactive_or_pending to unit_inactive would AFAIU lead to a conflict with the shutdown target if B.service was reactivated. (And if not, it could potentially make shutdown transaction infinite.) Thanks, Michal
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
