Graham Percival <gra...@percival-music.ca> writes: > On Thu, Dec 29, 2011 at 11:03:43AM -0700, Aleksandr Andreev wrote: >> Aha. Some Googling reveals that: >> >> Exit code 137: The job was killed because it exceeded the time limit. > > Don't top-post. > >> Any ideas how to up the time limit? > > Unless you have an incredibly under-powered computer (say, 10 > years old or more), don't increase the time limit. If any regtest > hits that boundary, it's a critical bug that needs fixing. Try to > figure out which regtest is doing this.
Exit code 137 usually corresponds to signal 9. On Posix systems, that is SIGKILL 9 Term Kill signal which more or less means that the process was killed by having another process explicitly kill it. It can happen as a consequence of having a CPU time limit (and the hard limit not being larger than the soft limit), see the manual page for ulimit: RLIMIT_CPU CPU time limit in seconds. When the process reaches the soft limit, it is sent a SIGXCPU signal. The default action for this signal is to terminate the process. However, the signal can be caught, and the handler can return control to the main program. If the process continues to consume CPU time, it will be sent SIGXCPU once per second until the hard limit is reached, at which time it is sent SIGKILL. (This latter point describes Linux 2.2 through 2.6 behavior. Implementations vary in how they treat processes which continue to consume CPU time after reaching the soft limit. Portable applications that need to catch this signal should perform an orderly termination upon first receipt of SIGXCPU.) But I don't consider this all too likely. What output do you get if you say ulimit -a on your command line? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel