An answer about the signal / error return status of a process... well... ok...
From the Bash man page (and generally in most shell documentation), waaay down in the section titled "Shell Grammer" and then "Simple Commands", there is an innocent statement reading thus:
The return value of a simple command is its exit status,
or 128+n if the command is terminated by signal n.
The return value of any shell (bash, sh, dash, ksh, csh, et al) process (simple command) is an 8-bit unsigned value, with the expected range of 0-255. Typical usage customs use zero (0) as 'success', and anything else as 'error'. The shell indicates that a process was interrupted/aborted/signaled by adding 128 to the signal value and using that as the return value.
If you're old enough, you might remember getting 'Error 139' (Signal 11) aborts during a kernel compile (it USED to take all night!) if you had flaky memory or overheating issues.
Error 137 indicates the apt-get process received a signal 9 (128+9=137), and signal 9 is KILL.
If you're fuzzy on the signal names vs numbers, look at the output of the kill -l
command:
$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
... lots more ... 64 total
Aha! Wonderful write up on Wikipedia, under Exit Status, specifically the Shell and scripts section. It explains that while a waitpid exit status of a process is an integer (int), shell processes only receive the lower 8 bits. It also talks about the '128+n' rationale. (Perhaps the wikipedia statement about ksh using '256+n' is incorrect, as the ksh man page says '128+n')
Peruse the wikipedia article, as it explains the various interpretations made by different programming languages and interfaces.
Hope this helps.
(And yes, I do read ALL the man pages, don't you?)
Addendum:
travis-ci does suggest to not use apt-get upgrade
(and by extension, apt-get dist-upgrade
) in the virtual machines. Install what you wish, but the VM's are generally well stocked and up-to-date.
Use of apt-get upgrade
may have contributed to apt-get receiving SIGKILL. Without further information from travis-ci, we're unable to determine exactly why. But, typically... SIGKILL is used when you've done something bad, excessive resource usage, high cpu usage and the like... again, we don't know, can't tell from the logs we've seen. (As an aside, look at ulimit (in bash man page), and setrlimit/getrlimit(2) and how its various limits are handled... RLIMIT_CPU (or -t) seems appropriate here)
sudo apt-get build-dep 0ad
without the quiet-qq
switch. :) You are asking for further information while you are closing his mouth with duct tape. Com'n man!137 - 128 = 9
... So your process received a signal 9... which we all recognize from the classic'kill -9 ...'
as the SIGKILL signal. InstaDeath™. Something (someone?) is sniping your apt-get process.apt-get
feedback should be improved?apt-get upgrade
... A word on apt-get upgrade