On Linux and with OpenJDK at least, the value returned by exitValue()
is the same as what a shell like zsh
or bash
and most sh
implementations (but not ksh93
or yash
) would assign to its $?
variable.
That is, it's:
- if the process exited with
exit(n)
or return n
from main()
: the lower 8 bits of n
(n & 0xFF
).
- if the process was killed by signal
n
: n + 128
.
So if you get a number of 130, there's an ambiguity in that you don't know whether the process dies of a signal 2 or just did an exit(130)
.
However, because so many shells follow that convention of having 128 + signal_number
, programs know to avoid using those values above 128 for their exit code (or when they do exit(130)
, it's to report the death of a child that dies of a signal 2 like some shells do under some circumstances).
So here, most likely, the process died of a signal 2. You can tell what signal that was by running:
$ kill -l 130
INT
at the prompt of a POSIX-style shell.
On most systems, signal 2 will be SIGINT. That's the signal that is sent to the foreground process group of a terminal when you press Ctrl-C in that terminal.
$ sleep 10
^C
$ echo "$?"
130
SIGINT should be reserved for terminal interrupt, and applications should not otherwise send it to other processes but there's nothing stopping them doing so, so it's still also possible that something did a kill(postgres_pid, SIGINT)
(kill -s INT
or kill -INT
or kill -2
in a shell).
$ sleep 10 &
[1] 20171
$ kill -s INT "$!"
[1] + interrupt sleep 10
$ wait "$!"
$ echo "$?"
130
Process.exitValue()
. See my edit.exit(errno)
. It's very uncommon for a command to do that. While a 130 shell exit status is very common and just means you've hit CTRL-C