somewhat confusing dinitctl restart output/semantic

[nekopsykose]

just a very small two gripes i noticed after using this for a while in chimera

• in systemd/openrc, restart on a stopped service brings it up. in dinit it prints cannot restart service; service not started..

  • this is probably a bit contentious/meaningless to change/care about, but afaict from a purely-user perspective i can't imagine why an operator would care about the distinction. the usual want is to 'take down and bring back up', and if it's already down then merely putting it back up seems like what would be wanted 99% of the time.
    (don't care too much about this, but just thought i'd ask why the current behaviour is the way it is, it's all good with me)

• the output message of a working restart is confusing because it merely prints Service 'x' started.

  • this seems now like it's doing the opposite of what is limited above- in systemd/openrc one could say there are two possibilities (either actual restart or just start), whereas here only restart is possible, yet it says "started" instead of "restarted".
    • anecdotally, a friend of mine trying dinit standalone for user services got really confused by this and thought they weren't running for a moment (pre-restart) just because of the missing re in front, so this at least is probably an easy patch?
  • and, because of this, this whole time i didn't realise the documented behaviour for --force was:

  --force
       Stop the service even if it will require stopping other services
       which depend on the specified service.  When applied to the
       restart command, this will cause the dependent services to also
       be restarted.
  

  this is because for example, usually for audio on a modern desktop you have (-> depends on):
  - wireplumber.user -> pipewire.user
  - pipewire-pulse.user -> pipewire.user
  - pipewire.user -> dbus, system stuff, etc
  and now the dinitctl -u restart -f pipewire is actually doing:
  - stop pipewire-pulse/wireplumber
  - stop pipewire
  - start pipewire
  - start pipewire-pulse/wireplumber
  but i had no idea as all that is printed is Service 'pipewire' started.. it would probably be nice to print the whole transaction? unrelatedly, what happens if one specific dependent fails during restart (i didn't check but i imagine some form of error gets printed).

[nekopsykose]

it would probably be nice to print the whole transaction?

of note, systemctl doesn't say anything whatsoever for these simple examples (on success only; iirc error handling is quite verbose about what unit failed), and openrc of course prints everything kinda (no parallelism and whatnot so i imagine that one is easier) of 'starting/stopping' in order + what is printed in shell

[davmac314]

Starting with the easier thing:

the output message of a working restart is confusing because it merely prints Service 'x' started.

Yes, I agree this could be a little better (it could say "restarted" instead of "started", ideally). Even better than that I suppose it should list the status of each affected service as they restart (or otherwise fail) but that it is a little complex to implement and not something I'm overly concerned with at the moment (contributions welcome...).

and, because of this, this whole time i didn't realise the documented behaviour for --force was:

I'm a little concerned that you would use an option called "--force" without understanding what it was doing :)

For the more complicated issue:

in systemd/openrc, restart on a stopped service brings it up. in dinit it prints cannot restart service; service not started.

This is because in Dinit, "restart" and "start" are fundamentally different in what they do, and that ties in to the service activation model (that is described in the dinitctl man page, in the "service operation" section; though maybe I should move that section to the dinit man page). This model is subtly different to what systemd and openrc use.

The "start" command activates a service, and starts it if it is not already started (because an activated service must be running).

The "restart" command restarts a service that is running, regardless of whether it is activated or not. It does not change the activation status of the service.

Since a service that isn't active, and which no other active service depends on, should not be running, it doesn't make sense for "restart" to start such a service (unless it was also going to mark the service active, but then there would be no way to restart a service that wasn't explicitly active; such a service can still be running if an active service depends on it).

Admittedly "start" isn't the best word for what "start" actually does, but I think it is the least confusing for most purposes (in general, "dinitctl start xyz" will have the result that people expect it to, i.e. the service will be started).

[nekopsykose]

hmm, ok. that makes sense to me, if start is basically a constraint then that makes sense :) it reminds me a bit of how apk add doesn't actually install a package. this seems quite similar.

that sounds completely ok- no need to change that. thanks for explaining!

I'm a little concerned that you would use an option called "--force" without understanding what it was doing :)

there's no other way i know of to restart something that has dependents. well, aside from first running stop on the dependents, then restarting the wanted service (or it stopping automatically if it was never active, as you mention), then starting the dependents again, but that is really clunky (and takes a while to type). is this not the intended way?

i assume (but didn't check) if there is only one dependent, then restarting that dependent will still not restart the service in this case because restart won't first stop the non-active dependency just to start it again and then finish the restart. so this requires multiple commands (or --force on the dependency).

the fastest way i can think of accomplishing this is activating something that depends on everything wanted (in this case, my-magic-thing -> wireplumber/pipewire-pulse -> pipewire), so then the command could be dinitctl stop my-magic-thing && dinitctl start my-magic-thing and it would restart the tree (instead of needing multiple stops+starts). but that's still not one command.

i guess this sounds like a separate feature request at this point (unless the -f is intended)

[davmac314]

there's no other way i know of to restart something that has dependents. well, aside from first running stop on the dependents, then restarting the wanted service (or it stopping automatically if it was never active, as you mention), then starting the dependents again, but that is really clunky (and takes a while to type). is this not the intended way?

It is! Sorry, my comment was supposed to be tongue-in-cheek, it was a reference to this:

this whole time i didn't realise the documented behaviour for --force was:

Implying that you had used "--force" but didn't realise what it was doing exactly. Perhaps I misunderstood.

i assume (but didn't check) if there is only one dependent, then restarting that dependent will still not restart the service in this case because restart won't first stop the non-active dependency just to start it again and then finish the restart. so this requires multiple commands (or --force on the dependency).

Correct.

so then the command could be dinitctl stop my-magic-thing && dinitctl start my-magic-thing and it would restart the tree

Well, it might, if you give it enough time between the two commands; otherwise not all the dependencies may actually stop. If you really need to restart a tree (why?) then you should "stop" the root (with --force), and then "start" each of the leaves. Or just use "restart --force" (on the root), that's what it's for.

[nekopsykose]

ah! okay, the joke went totally over my head, then --force works as intended and is exactly what i needed for that paragraph :)

but you are right i should've read what it did in more detail than 'allows restarting with dependents' haha

ok, that answers all my questions then :) thank you very much!