Why is systemd dropping options when using 'service start' ?
Man page of 'service' defines the service command as :
service SCRIPT COMMAND [OPTIONS]
and states
service passes COMMAND and OPTIONS to the init script unmodified.
Now take this init script for some service named "foo" :
#!/bin/sh
case "$1" in
start)
echo $2 >> output
;;
someaction)
echo $2 >> output
;;
esac
exit 0
On a system using systemd, after daemon-reload, service foo start bar writes nothing in output file while service foo someaction bar writes "bar" as expected. (Tested on Ubuntu 16.04)
On a system without systemd, both commands write "bar" as expected. (Tested on Mint 17.1)
I would bet stop command does the same.
Why are options dropped when start is called and not other "custom" commands?
The service command was designed for SysV init scripts, not systemd. On systemd based systems, the service command may continue to exist as a shim to translated old syntax into new syntax. On Ubuntu 16.04, /usr/sbin/serviceis a bash script, so you you can read the source code and see where it has is_systemd conditional clauses. When looking at the start command on a systemd-based systems, you'll see this:
systemctl $sctl_args ${ACTION} $unit
In other words, no additional args are passed through in this translation layer.
The replacement for service on systemd-based system is systemctl, with systemctl start your-service-name being used to start a service.
systemd does not support adding custom actions, but you can create custom units easily, so you could then do:
systemctl start myservice-someaction