ssh email@example.com "sudo /etc/init.d/smokeping reload"
(1) (or in your example the shell started by PHP's
exec()) will parse that command line and if found execute a
(2) Command which will contact a
(3) Server on
xxx.xxx.xxx.xx which after successful authentication will call a
(4) Which will interpret that
sudo command line and run the
(5) Command which after checking permissions will run
(6) Which itself is probably a shell script that runs several commands.
Several things may fail there. If all the steps one to 5 are successful, then the exit status of
/etc/init.d/smokeping will be reported to your shell because
sudo does report the exit status of the command it runs and the remote shell exits with the exit status of the last command it ran and
ssh reports the exit status of the remote shell.
Now, commands return a non-zero exit status, by convention, to report to the caller that they've not managed to do what they were asked to do.
In your case, either
/etc/init.d/smokeping decided that whatever error occurred was not enough to warrant a non-zero exit status, or that script is not written correctly and fails to return with a non-zero exit status upon failure (or some pathological case involving misbehaviour or misconfiguration of
sudo or the remote shell).
/etc/init.d scripts are often written with
set -e. With that flag enabled, the shell interpreting the script will by default exit when a command it runs fails (with the non-zero exit status of the failing command), which makes me think here we may be in the first situation: "smokeping" does decide to report that it has successfully reloaded.
An example of a pathological case could be for instance:
bash used as the remote shell (
bash does read the
~/.bashrc when invoked over
ssh even though those are not interactive shells), and the
~/.bashrc has something like:
trap 'whatever...; exit 0' EXIT
Which would cause the exit status of interactive shells or shells started over
rsh to always be