[systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Lennart Poettering]

On Wed, 04.02.15 22:10, Uoti Urpala (uoti.urpala at pp1.inet.fi) wrote:

> On Wed, 2015-02-04 at 19:36 +0100, Lennart Poettering wrote:
> > On Wed, 04.02.15 20:19, Uoti Urpala (uoti.urpala at pp1.inet.fi) wrote:
> > > You're missing an essential point here: there's a distinction between
> > > skipping reloads for services which have not not been dispatched, and
> > > skipping reloads for services for which startup code is already running
> > > (and may be using existing configuration) but which have not reached
> > > full "running" status yet.
> > > 
> > > The former is the correct behavior (but currently handled wrong by
> > > systemd!), and never causes races. Only the latter can cause races like
> > > described above.
> > 
> > These two cases aren't that different. If somebody pushes an
> > additional job into the queue that wants to run before the reload but
> > after the service is up you cannot ot flush out the reload just
> > because the service has not started yet...
> 
> I cannot parse what you're trying to say here, if it's anything
> meaningful. 

No, usually what I am babbling is not meaningful at all...

> Your "wants to run before the reload" sounds like you're
> talking about guaranteeing that a reload NOT happen before something
> else runs, but that would be nonsense - the "guarantee" would guarantee
> nothing semantically relevant (if systemd only starts executing the
> service binary *after* the reload has been queued, it cannot use any
> pre-reload-order config at any point; there's no "guaranteed to use old
> config" guarantee of any form possible!).

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...

Lennart

-- 
Lennart Poettering, Red Hat