<div dir="ltr"><div>I submitted this patch because on CentOS 7, the usage 'service <name> status -l' works;<br>and I found it doesn't work on Debian, without a warning.<br></div><div>I agree the service(8) command is a compatibility wrapper for many different init systems,<br></div><div>so those systemctl specific options cannot be used with other init systems. Adding a warning<br></div><div>message to tell user the options are ignored when invoking systemctl, if any options are given,<br></div><div>should be also fine. <br> </div></div><br><div class="gmail_quote"><div dir="ltr">Andreas Henriksson <<a href="mailto:andreas@fatal.se">andreas@fatal.se</a>>于2018年4月26日周四 下午6:16写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Not that my opinion really counts, but still....<br>
<br>
On Thu, Apr 26, 2018 at 11:12:33AM +0200, Michael Biebl wrote:<br>
> On Thu, 26 Apr 2018 16:26:03 +0800 WHR <<a href="mailto:msl0000023508@gmail.com" target="_blank">msl0000023508@gmail.com</a>> wrote:<br>
[...]<br>
> > The service(8) script should pass additional options, if any after '${ACTION}', to systemctl(8).<br>
[...]<br>
> I'm uncertain about this. If you want all features of systemd/systemctl,<br>
> I think you should use systemctl directly.<br>
> service is more of wrapper which hides the differences between<br>
> alternative init systems (sysv, systemd, openrc) and is sort of the<br>
> least common denominator.<br>
<br>
I agree, but on the other hand this is the documented syntax (from<br>
manpage):<br>
<br>
        service SCRIPT COMMAND [OPTIONS]<br>
<br>
Also...<br>
<br>
        service passes COMMAND and OPTIONS to the init script unmodified.<br>
<br>
So I think the patch is technically correct (and thanks submitter for<br>
including a patch!).<br>
<br>
This still leaves me torn. While the patch implements the documented<br>
behaviour, but I personally see service as the "portable" command.<br>
By allowing init dependent things to be passed that portability is<br>
broken (and then it provides no value over init dependent equivalents).<br>
I guess the bigger question is: Should the OPTIONS field be deprecated?<br>
Thanks a much bigger task and breaking compatibility for things<br>
that's not in the archive and has to be fixed up by users isn't nice.<br>
I guess the minimum bar if maintainers decide deprecation is the best<br>
is to simply document the deprecation and leave the sysvinit<br>
implementain still functional.<br>
<br>
(Maybe to be taken into consideration: How does other distributions<br>
service commands work? We all use different implemations IIRC?!)<br>
<br>
Regards,<br>
Andreas Henriksson<br>
<br>
</blockquote></div>