On Wed, 2015-02-04 at 21:57 +0100, Lennart Poettering wrote: > OK, let's try this again, with an example: > > a) you have one service mydaemon.service > > b) you have a preparation service called > mydaemon-convert-config.service that takes config from somewhere, > converts it into a suitable format for mydaemon.service's binary > > Now, you change that config that is located somewhere, issue a restart > request for m-c-c.s, issue a reload request for mydaemon.service. > > Now, something like this should always have the result that your > config change is applied to mydaemon.service. Regardless if > mydaemon.service's start was queued, is already started or is > currently being started. You are suggesting that the reload can > suppressed when a start is already enqueued, but that's really not the > case, because you first have to run m-c-c.s, before you can reload...
I do not see why that would cause any problems with removing the blocking. If you mean literally running "systemctl restart mydaemon-convert-config.service; systemctl reload mydaemon.service" then this should still work fine - the first "restart" will block until the operation is complete and new config exists, and then the "reload" guarantees that no old config is in use. However, I don't see why you'd include the part about creating the new configuration via mydaemon-convert-config.service in this case - the new configuration already exists before any "reload" functionality is invoked, so why the irrelevant complication of creating that configuration via another service? It seems you are implicitly assuming some kind of parallel execution of the restart and the reload? If you mean something like "systemctl restart --no-block mydaemon-convert-config.service; systemctl reload mydaemon.service", I don't see why you'd ever /expect/ this to work with any reload semantics - isn't this clear user error, and will be racy with current systemd code just as much as the proposed fix? There are no ordering constraints here, any more than there would be about starting two services and expecting the first request to be started first. And in any case I'd consider the semantics of reload to be "switch to configuration equal or newer than what existed *when the reload was requested*", without any guarantees that changes from operations queued but not finished before calling reload would be taken into account. So unless I completely misunderstood your example, it seems that this does NOT demonstrate any problems with removing the blocking. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
