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