2

I'm trying to build 0ad on the travis-ci service and I'm randomly experiencing failures of apt-get install (or apt-get dist-upgrade) with returncode 137 without any further information. travis-ci is based on Ubuntu 12.04. What is 137 indicating? An example output can be found at https://travis-ci.org/krichter722/0ad/jobs/92938434.

Some more system information.

$ uname -a && lsb_release -a
Linux testing-worker-linux-89e97461-1-15272-linux-4-69692739 2.6.32-042stab090.5 #1 SMP Sat Jun 21 00:15:09 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 12.04 LTS
Release:    12.04
Codename:    precise
6
  • 1
    Try 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!
    – user.dz
    Nov 24, 2015 at 13:30
  • Return codes larger than 127 generally indicate the process received an unhandled signal. 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.
    – lornix
    Nov 24, 2015 at 14:24
  • @lornix Very helpful, thanks. Do I have any change to figure out what's actually wrong if the issue happens on the travis-ci.org service before getting in contact with them and figuring out whether apt-get feedback should be improved? Nov 24, 2015 at 15:01
  • 1
    Perhaps you're bumping up against a runtime limit? memory limit? cpu time limit? Possibly try the apt-get dist-upgrade with --download-only, then re-run to perform the install. You're asking their system to do an awful lot of work. Sure sounds like your process is getting killed due to some limit being reached. Trying 'taking smaller bites' to get things done. Other than that, I'm shotgunning things here.
    – lornix
    Nov 24, 2015 at 15:05
  • 1
    To be honest, they DO ask that you not run apt-get upgrade... A word on apt-get upgrade
    – lornix
    Nov 24, 2015 at 15:29

2 Answers 2

3

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)

2
  • 1
    Nice, could you please add that travis-ci help link about apt-get upgrade too. It could be the source of the problem and it will help coming users.
    – user.dz
    Nov 26, 2015 at 10:43
  • "And yes, I do read ALL the man pages, don't you?" -> No, I believe in links ;) Thank you very much! Nov 26, 2015 at 14:38
1

As there no error message from apt-get, I could agree with @lornix idea. But I only expect problem with available size in file-system quota or it could be the parallel download feature of apt-get. (It uses a thread for each source by default)

Here quite optimized to minimize resources (but more longer time)

uname -a && lsb_release -a && df
sudo apt-get update
sudo apt-get install python-software-properties
sudo add-apt-repository --yes ppa:wfg/0ad.dev
sudo add-apt-repository --yes ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get remove oracle-java7-installer oracle-java8-installer postgresql-9.2 postgresql-contrib-9.2 postgresql-9.2-postgis-2.1 postgresql-9.3 postgresql-contrib-9.3 postgresql-9.3-postgis-2.1 postgresql-9.4 postgresql-contrib-9.4 postgresql-9.4-postgis-2.1 postgresql-9.1 postgresql-9.1-postgis-2.1 postgresql-9.1-postgis-scripts postgresql-9.2-postgis-scripts postgresql-9.3-postgis-scripts postgresql-9.4-postgis-scripts postgresql-client postgresql-client-9.1 postgresql-client-9.2 postgresql-client-9.3 postgresql-client-9.4 postgresql-client-common postgresql-common postgresql-contrib-9.1
yes | sudo apt-get -o Acquire::Queue-mode=access -yy --yes upgrade
yes | sudo apt-get -o Acquire::Queue-mode=access -yy --yes dist-upgrade

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .