Re: [systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command
On Thu, Oct 10, 2019 at 4:46 AM Colin Guthrie wrote: > > Andy Pieters wrote on 08/10/2019 11:41: > > 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 > > > FWIW I'd tend to agree with you. > > > [colin@jimmy Channel (master)]$ sudo systemctl stop --fodslkjsf httpd > > systemctl: unrecognized option '--fodslkjsf' I think this error checking happens automatically with getopt_long(3). > [colin@jimmy Channel (master)]$ sudo systemctl stop --now httpd > > [colin@jimmy Channel (master)]$ > > > If --now is irrelevant to the verb, then it should be the equiv of an > unrecognized option. > > Bonus points if it issued a git-style "did you mean systemctl disable > --now ..." error response. This would not be caught by getopt_long(3) because it has no way of knowing about "verbs" or the options that are valid for them. This kind of error checking would require special-case coding in the systemctl code. This is more likely to happen if someone submits a PR for it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command
Andy Pieters wrote on 08/10/2019 11:41: > 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 FWIW I'd tend to agree with you. [colin@jimmy Channel (master)]$ sudo systemctl stop --fodslkjsf httpd systemctl: unrecognized option '--fodslkjsf' [colin@jimmy Channel (master)]$ sudo systemctl stop --now httpd [colin@jimmy Channel (master)]$ If --now is irrelevant to the verb, then it should be the equiv of an unrecognized option. Bonus points if it issued a git-style "did you mean systemctl disable --now ..." error response. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command
On Tue, 8 Oct 2019 at 10:47, Reindl Harald wrote: > > > > Am 08.10.19 um 08:09 schrieb Ulrich Windl: > Reindl Harald schrieb am 07.10.2019 um 12:48 in > > Nachricht <8c0ef6cf-7b51-c257-d974-b4b39b489...@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@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command
Am 08.10.19 um 08:09 schrieb Ulrich Windl: Reindl Harald schrieb am 07.10.2019 um 12:48 in > Nachricht <8c0ef6cf-7b51-c257-d974-b4b39b489...@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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command
>>> Reindl Harald schrieb am 07.10.2019 um 12:48 in Nachricht <8c0ef6cf-7b51-c257-d974-b4b39b489...@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. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
