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).<div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>* 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.</div><div><br></div><div>* 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.</div><div><br></div><div> 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.</div><div><br></div><div> 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: <a href="https://github.com/systemd/systemd/issues/10638">https://github.com/systemd/systemd/issues/10638</a>). 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).</div><div><br></div><div> 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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br><div><br>On Monday, January 7, 2019, Michal Koutný <<a href="mailto:mkoutny@suse.com">mkoutny@suse.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Bringing up an older one.)<br>
<br>
On 1/15/18 2:20 AM, 林自均  wrote:<br>
> I've filed <a href="https://github.com/systemd/systemd/issues/7877" target="_blank">https://github.com/<wbr>systemd/systemd/issues/7877</a> for this.<br>
There's also accompanying RFE at [1]. I've looked into that and arrived<br>
at design/implementation crossroads. I'd be happy for any ideas/feedback<br>
on that GH issue.<br>
<br>
Thanks,<br>
Michal<br>
<br>
[1] <a href="https://github.com/systemd/systemd/issues/8102" target="_blank">https://github.com/systemd/<wbr>systemd/issues/8102</a><br>
<br>
<br>
</blockquote></div></div>