[systemd-devel] systemctl start second.service first.service

[Jonathon Kowalski]

So I have a comment on the issue, but it's been quite a lot of time since
then (and I happen to know more about systemd than I did back then). I
think this feature is just working around problems in units, and
introducing more complexity for little gain, in particular, while
StartUnits vectorized call is probably the most obvious, it is perhaps the
most complex solution of all three (now introducing the idea of more than
one anchor job for generating a transaction and job sets).

The example given in the report is about smb and nfsd, in that ordering
only matters as long as both are part of a transaction. I presume this was
put in the unit keeping in mind that a target will pull both (which then
causes ordering to be maintained in the generated transaction). I think
systemctl should do something similar to that, internally create a
transient target unit through manager's bus API, add Wants= (which gives it
implicit After=) on all unit names passed, and then invoke the startup of
this target, so that it gets treated as anchor job and generates a
transaction where all dependencies are ordered properly. Hence, I vote for
the first option.

You point out two issues, unclear management of unit, and lack of a
equivalent D-Bus operation to do this, so I guess then PID1 could perhaps
do this itself, when a StartUnits method is invoked, takes the array of all
units, generates a target, adds dependencies, and then generates a
transaction for it as anchor job. It would perhaps need new
RestartUnits/StopUnits/ReloadUnits operations to complement the vectorized
start, and reload-or-restart or try-reload-or-restart equivalents, and I
think all of these can already be expressed through propagative deps in the
target unit, except two key things:

* For {Stop/Restart}Units, systemd would need to gain ConsistsOf=
dependency to be specified in a unit, so that modifying properties of other
units is not needed on fly, which would then propagate the job as it does
today. This also means the current internal fallback to TRY_RESTART on
propagation of restart jobs to not wake up dependencies also needs to be
changed.

* Getting reload-or-restart or try-reload-or-restart to work through
propagation will be tricky, so either their vectorized types need to be
dropped from consideration, or some work has to done to get them in shape.

 So currently, reload-or-restart calls the method ReloadOrRestart, which
will resolve to either JOB_RELOAD_OR_START if target unit has propagation
of reload defined, otherwise JOB_RESTART.

 Now, in transaction, if target supports reload the resolved
JOB_RELOAD_OR_START is collapsed to start job for inactive/deactivating
units and reload job for other units, this means when targets enable reload
propagation, reload-or-restart despite use of PartOf= in target unit does
not propagate restart to units it can. This needs fixing, perhaps through a
new JOB_RELOAD_OR_RESTART which collapses to one of the two, or some other
way of solving it (pointed out by Andrei Borzenkov here:
https://github.com/systemd/systemd/issues/10638). Note that this tuning
happens at call time, as the intent is to decide at method call time, in
functions that are mapped to bus methods, which one of these operations
should be triggered (as user is triggering them after inspecting state from
their perspective), and I think JOB_RELOAD_OR_START will also never appear
in a transaction as it is collapsed to a simpler type before, so same
should hold for JOB_RELOAD_OR_RESTART (TRY variants do, for reload and
restart, as they are intended to be less strict to hold assumptions made
about unit state client side).

 Same holds for try-reload-or-restart, except the function that builds the
logic before collapsing happens could take a bool to resolve these to
either TRY_RESTART or TRY_RELOAD, for each unit.

So for now I guess the stateful types can be dropped that do collapsing
because that is a lot of work, and perhaps some work towards a simple
patchset covering start/stop/restart/reload. So I vote for both 2 and 1, 2
implemented using the 1st approach.

That said, I do think in practice if units are declared properly dependency
wise, they should already pull one another in a transaction, which would
then also take care of ordering deps, and anything that actually needs such
semantics from systemctl (or through the bus) is already broken.

On Monday, January 7, 2019, Michal Koutný <mkoutny at suse.com> wrote:

> (Bringing up an older one.)
>
> On 1/15/18 2:20 AM, 林自均  wrote:
> > I've filed https://github.com/systemd/systemd/issues/7877 for this.
> There's also accompanying RFE at [1]. I've looked into that and arrived
> at design/implementation crossroads. I'd be happy for any ideas/feedback
> on that GH issue.
>
> Thanks,
> Michal
>
> [1] https://github.com/systemd/systemd/issues/8102
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190108/f66ca90d/attachment.html>