3

When attempting to start PostgreSQL server using the /usr/pgsql-9.2/bin/postgres command I get an exit value code of 130.

However I could not find any documentation for the exit codes of this command. What does 130 mean?

FYI the command is executed from a java code which basically looks like this:

Process dbProcess = Runtime.getRuntime().exec(cmd);
...
int exitCode = dbProcess.exitValue();
  • Could you please clarify what you mean by "exit value" and how you obtain it? Is it from a $?/$status shell variable? Which shell? – Stéphane Chazelas Aug 14 '15 at 11:03
  • @StéphaneChazelas The exit value is obtained in java code with Process.exitValue(). See my edit. – fiddler Aug 14 '15 at 11:34
  • It doesn't seem Oracle document what it is. Chances are it's going to be the same as the $? of shells like the Bourne shell, zsh or bash (seems to be the case for openjdk on Linux), that is the value is the lowest 8 bits of the number passed to exit() or 0x80 + signal_number if the process was killed. – Stéphane Chazelas Aug 14 '15 at 12:00
  • I found this answer which could be related to my issue: stackoverflow.com/questions/7348465/… – fiddler Aug 14 '15 at 12:11
  • 1
    @cuonglm's answer is probably a red herring. It's very unlikely that postgres does a 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 – Stéphane Chazelas Aug 14 '15 at 12:31
5

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
  • All right. But here I didn't start my process in a terminal and I didn't stop it with Ctrl-C. So what could be the cause of this exit value? – fiddler Aug 14 '15 at 12:44
  • @fiddler, SIGINT should be reserved for terminal Ctrl-C, and applications should not otherwise send it to other processes but there's nothing stopping them doing so, so it's still possible that something did a kill(postgres_pid, SIGINT) (kill -s INT "$postgres_pid" in a shell). You may want to look at the postgres logs for more information. – Stéphane Chazelas Aug 14 '15 at 12:48
  • 1
    I'd suggest that looking at the log files should be one of the first things to do. – roaima Aug 14 '15 at 12:56
  • @fiddler, any confirmation from the logs? – Stéphane Chazelas Aug 14 '15 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.