[systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command
Andy Pieters
systemd at andypieters.me.uk
Tue Oct 8 10:41:55 UTC 2019
On Tue, 8 Oct 2019 at 10:47, Reindl Harald <h.reindl at thelounge.net> wrote:
>
>
>
> Am 08.10.19 um 08:09 schrieb Ulrich Windl:
> >>>> Reindl Harald <h.reindl at thelounge.net> schrieb am 07.10.2019 um 12:48 in
> > Nachricht <8c0ef6cf-7b51-c257-d974-b4b39b489c25 at thelounge.net>:
> >
> >> Am 07.10.19 um 12:43 schrieb Andy Pieters:
> >>> Just lately ran into a fumble. I was trying to stop and disable a
> >>> service and I typed in:
> >>>
> >>> systemctl stop --now example.service
> >>
> >> but nowehere "disable" is statet with that command
> >>
> >>> The service duly stopped but wasn't disabled because the --now switch
> >>> is only applicable on the disable/enable/mask commands
> >>
> >> yes, it "executes the state" instead just disable it for the next boot
> >> but "stop now" don't imply a different behavior as "stop" unless there
> >> would be some timing to exectue "stop" by default which isn't
> >>
> >>> However, shouldn't it be good practice to produce a warning or an
> >>> error when a switch is used that has no effect?
> >>
> >> it is used, it is stopped *now*
> >
> > The question was different. With "The start or stop operation is only carried out when the respective enable or disable operation has been successful." one could even argue that a "stop --now" also disables the service. If an option does not apply, there should be a warning that it is ignored, or maybe even better: An error should be raised.
>
> i understand the question well but i don't see why one would argue that
> "stop --now" also disables the service instead just stop it
>
> what if systemd later get a way to say "systemctl stop --datetime
> '2019-11-15 18:30'" on the fly and --now has a completly unlogical context
>
> --now is just a convenience option
>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
forget about the stop. that was the context into which I discovered it.
I am not saying stop should disable I am saying stop should not accept
now and silently ignore it
More information about the systemd-devel
mailing list