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

[Michal Koutný]

Thanks for your exhaustive reply, Jonathon.

On Tue, Jan 08, 2019 at 04:02:47AM +0530, Jonathon Kowalski <bl0pbl33p at gmail.com> wrote:
> [...]
> 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.
I agree, this recycles most of the existing transaction engine logic and
does not bring too many corner cases needing resolution.

> [...] So I vote for both 2 and 1, 2 implemented using the 1st
> approach.
Problem with 2 is that it touches DBus API and hence it should be a well
considered change. I don't think it's good to create such "macro"
functions that would emulate something that could be done by other DBus
methods (create the transient target, add deps for it, start it).

> 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.
This is an argument I did not contemplate enough but once you pointed it
out, I cannot agree more :)

Units themselves should specify what they Wants= or Requires= in the
transaction. This may be distributed in another unit, e.g.
- U wants A and B,
- B after A,
- intended usecase is starting U.

The manual invocation of `systemctl start B A` could be then understood
rather as debugging operation.

In this light, it makes a nice sense to me to introduce a new option to
systemctl, that'd make sure a transient target is created and it
aggregates the requested operations.

Management of that unit then can be no special from others because by
passing that unit, user should be expecting such a unit is created.

You've concinced me about variant 1 with the behavior being triggered by
explicit user request.

Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190118/95ee2721/attachment.sig>