I wrote a
cron job, which uses
ssh to run a script on a server. I just tried running the script, and now I am unhappy.
client# ssh server.local /usr/local/bin/script client# server# /usr/local/bin/script Segmentation fault (core dumped) server# client# ssh server.local /usr/local/bin/script client# echo $? 255
I can confirm the crash is in the script interpreter,
/bin/sh (a symlink to
/bin/dash). For example, when I ran
script & on the server, the shell tells me the background job has PID 30860, and that is the next PID that shows up in the list of crashes in
coredumpctl. I will need to solve the crash, but this question is only about how to detect such crashes.
cron supports error reporting by "sending mail" when a job prints any message. But it does not mail on non-zero exit status. So my current cron job would not mail me about this error. (And if it did, I would really like to have a more helpful pointer for troubleshooting than "Exited with code 255").
cron is relying on the Unix convention, that "no news is good news". But that convention is being broken here.
I interpret this as a limitation of SSH. If I wanted to always notice segmentation faults in remote commands, what rule could I follow, to work around this SSH limitation?
(I'm also interested if there's a "good reason" for this limitation. I think I know more-or-less how it could happen, at the implementation level).