[systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command

[Reindl Harald]

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