I submitted this patch because on CentOS 7, the usage 'service <name>
status -l' works;
and I found it doesn't work on Debian, without a warning.
I agree the service(8) command is a compatibility wrapper for many
different init systems,
so those systemctl specific options cannot be used with other init systems.
Adding a warning
message to tell user the options are ignored when invoking systemctl, if
any options are given,
should be also fine.

Andreas Henriksson <andr...@fatal.se>于2018年4月26日周四 下午6:16写道:

> Hi,
>
> Not that my opinion really counts, but still....
>
> On Thu, Apr 26, 2018 at 11:12:33AM +0200, Michael Biebl wrote:
> > On Thu, 26 Apr 2018 16:26:03 +0800 WHR <msl0000023...@gmail.com> wrote:
> [...]
> > > The service(8) script should pass additional options, if any after
> '${ACTION}', to systemctl(8).
> [...]
> > I'm uncertain about this. If you want all features of systemd/systemctl,
> > I think you should use systemctl directly.
> > service is more of wrapper which hides the differences between
> > alternative init systems (sysv, systemd, openrc) and is sort of the
> > least common denominator.
>
> I agree, but on the other hand this is the documented syntax (from
> manpage):
>
>         service SCRIPT COMMAND [OPTIONS]
>
> Also...
>
>         service passes COMMAND and OPTIONS to the init script unmodified.
>
> So I think the patch is technically correct (and thanks submitter for
> including a patch!).
>
> This still leaves me torn. While the patch implements the documented
> behaviour, but I personally see service as the "portable" command.
> By allowing init dependent things to be passed that portability is
> broken (and then it provides no value over init dependent equivalents).
> I guess the bigger question is: Should the OPTIONS field be deprecated?
> Thanks a much bigger task and breaking compatibility for things
> that's not in the archive and has to be fixed up by users isn't nice.
> I guess the minimum bar if maintainers decide deprecation is the best
> is to simply document the deprecation and leave the sysvinit
> implementain still functional.
>
> (Maybe to be taken into consideration: How does other distributions
> service commands work? We all use different implemations IIRC?!)
>
> Regards,
> Andreas Henriksson
>
>

Reply via email to