You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bundle install step is assumed to have succeeded when OOM killed #554
Thanks for reporting this! It looks like this is an edge case that sshkit is not handling.
Ideally, what would you like sshkit to do in this scenario? Just logging that the command was killed is probably insufficient, because that would mean execution would just continue to the next step. I'm guessing you'd like an exception raised in this scenario?
Right now, when running a command, sshkit accepts an option :raise_on_non_zero_exit, which defaults to true. If the command is killed with a signal, we could treat this as "non-zero exit", which then cause an exception to be raised by default.
Or, we could introduce a new option, :raise_on_killed_by_signal, default that to true. That would allow us to treat non-zero exit and killed as separate scenarios, which seems more correct to me.
Posix mandates for the shell that
"The exit status of a command that terminated because it received a signal shall be reported as greater than 128."
While sshkit is not a Posix shell and thus not bound by that, I'd argue that treating "killed by signal" any differently from "exited nonzero" still violates the Law of Least Astonishment.
In case the user desires detailed information about the death of a process, the best thing to do is to hand them two integers: both the exit code and the signal number (or 0 if the process didn't die to a signal).
Activity
mattbrictson commentedon Mar 21, 2025
Thanks for reporting this! It looks like this is an edge case that sshkit is not handling.
Ideally, what would you like sshkit to do in this scenario? Just logging that the command was killed is probably insufficient, because that would mean execution would just continue to the next step. I'm guessing you'd like an exception raised in this scenario?
Right now, when running a command, sshkit accepts an option
:raise_on_non_zero_exit, which defaults to true. If the command is killed with a signal, we could treat this as "non-zero exit", which then cause an exception to be raised by default.Or, we could introduce a new option,
:raise_on_killed_by_signal, default that to true. That would allow us to treat non-zero exit and killed as separate scenarios, which seems more correct to me.schnittchen commentedon Mar 21, 2025
I think a new option is more clear. And I think for 99.999% of all use cases, the option makes sense to be true, so that should be the default.
braun2morrow commentedon Mar 18, 2026
Posix mandates for the shell that
"The exit status of a command that terminated because it received a signal shall be reported as greater than 128."
While sshkit is not a Posix shell and thus not bound by that, I'd argue that treating "killed by signal" any differently from "exited nonzero" still violates the Law of Least Astonishment.
In case the user desires detailed information about the death of a process, the best thing to do is to hand them two integers: both the exit code and the signal number (or 0 if the process didn't die to a signal).