[Kernel-packages] [Bug 1308474] Re: CPU-intensive processes killed by OS
** Tags added: kernel-bug-exists-upstream -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1308474 Title: CPU-intensive processes killed by OS Status in “linux” package in Ubuntu: Confirmed Bug description: When testing some algorithm I ran the test program several times with different parameters. It was to be expected that each run takes about four hours, and to utilize the capacities of my computer (4 CPUs) I started the program 4 times running in parallel and with lowered priority (the latter to be able to do meanwhile something else on the computer). All four processes ran in parallel for a few minutes but then two of them were killed with the error message: Command terminated by signal 9 [1] Exit 137/usr/bin/time -f '%U+%S sec, avg %Kk max %Mk memory, major %F minor %R faults, %I+%O i/o' ./testu01long -d9689 -b3 cat9689.tub Here, /usr/bin/time ... is the command I launched for the first process, the second error message was quite similar, now for the second process. The process started first ran about 6 minutes, the second about 14 minutes, so the TERM signals have been issued at different times (the processes had been started within one minute). The two other processes continued without problems. The point is that I did NOT issue a TERM signal to the processes, I conclude that the OS issued the TERM signals. The effect can be repeated to some extend: if another CPU-intensive process is started (e.g. a lengthy compilation) then an already running CPU-intensive process may be killed, if so then the one first started. When the killed program had been relaunched with the same parameters but without concurrency of other CPU-intensive processes (e.g. only editing, reading e-mails running in parallel) then all things were fine, so the kill is really not caused by the program. The program does not use external devices and even no I/O except for writing a summary to stdout at program end (i.e. not when the processes were killed). The question is, why have the processes been killed? Is the OS unable to manage as many running processes? I consider this a bug in the OS, part process management. The bug implies that the computer can be used for light weight tasks only. With regards Dr. Wolfgang Jansen PS: Additional platform info (commands ulimit -a, top when two CPU-intensive processes were still running): core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30092 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30092 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited --- Tasks: 244 total, 3 running, 241 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 1.2 sy, 27.5 ni, 54.6 id, 1.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3930376 total, 2263872 used, 1666504 free,36756 buffers KiB Swap: 9212 total, 9212 used,0 free, 705612 cached PID USER PR NI VIRT RES SHR S P %CPU %MEM TIME COMMAND 18804 wolfgang 30 10 14632 960 648 R 1 103.0 0.0 95:09 testu01long 18817 wolfgang 30 10 14632 960 648 R 0 103.0 0.0 94:03 testu01long 2491 root 20 0 444m 128m 103m S 2 6.4 3.3 7:04 Xorg 2945 wolfgang 20 0 1950m 205m 11m S 2 6.4 5.4 13:08 cinnamon 1 root 20 0 27336 15360 S 1 0.0 0.0 0:01 init 2 root 20 0 000 S 3 0.0 0.0 0:00 kthreadd 3 root 20 0 000 S 0 0.0 0.0 0:00 ksoftirqd/0 5 root 0 -20 000 S 0 0.0 0.0 0:00 kworker/0:0H 7 root rt 0 000 S 0 0.0 0.0 0:00 migration/0 8 root 20 0 000 S 0 0.0 0.0 0:00 rcu_bh 9 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/0 10 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/1 11 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/2 12 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/3 13 root 20 0 000 S 3 0.0 0.0 0:27 rcu_sched 14 root
[Kernel-packages] [Bug 1308474] Re: CPU-intensive processes killed by OS
This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug. Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org. Once this bug is reported upstream, please add the tag: 'kernel-bug- reported-upstream'. [0] https://wiki.ubuntu.com/Bugs/Upstream/kernel ** Changed in: linux (Ubuntu) Status: Confirmed = Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1308474 Title: CPU-intensive processes killed by OS Status in “linux” package in Ubuntu: Triaged Bug description: When testing some algorithm I ran the test program several times with different parameters. It was to be expected that each run takes about four hours, and to utilize the capacities of my computer (4 CPUs) I started the program 4 times running in parallel and with lowered priority (the latter to be able to do meanwhile something else on the computer). All four processes ran in parallel for a few minutes but then two of them were killed with the error message: Command terminated by signal 9 [1] Exit 137/usr/bin/time -f '%U+%S sec, avg %Kk max %Mk memory, major %F minor %R faults, %I+%O i/o' ./testu01long -d9689 -b3 cat9689.tub Here, /usr/bin/time ... is the command I launched for the first process, the second error message was quite similar, now for the second process. The process started first ran about 6 minutes, the second about 14 minutes, so the TERM signals have been issued at different times (the processes had been started within one minute). The two other processes continued without problems. The point is that I did NOT issue a TERM signal to the processes, I conclude that the OS issued the TERM signals. The effect can be repeated to some extend: if another CPU-intensive process is started (e.g. a lengthy compilation) then an already running CPU-intensive process may be killed, if so then the one first started. When the killed program had been relaunched with the same parameters but without concurrency of other CPU-intensive processes (e.g. only editing, reading e-mails running in parallel) then all things were fine, so the kill is really not caused by the program. The program does not use external devices and even no I/O except for writing a summary to stdout at program end (i.e. not when the processes were killed). The question is, why have the processes been killed? Is the OS unable to manage as many running processes? I consider this a bug in the OS, part process management. The bug implies that the computer can be used for light weight tasks only. With regards Dr. Wolfgang Jansen PS: Additional platform info (commands ulimit -a, top when two CPU-intensive processes were still running): core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30092 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30092 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited --- Tasks: 244 total, 3 running, 241 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 1.2 sy, 27.5 ni, 54.6 id, 1.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3930376 total, 2263872 used, 1666504 free,36756 buffers KiB Swap: 9212 total, 9212 used,0 free, 705612 cached PID USER PR NI VIRT RES SHR S P %CPU %MEM TIME COMMAND 18804 wolfgang 30 10 14632 960 648 R 1 103.0 0.0 95:09 testu01long 18817 wolfgang 30 10 14632 960 648 R 0 103.0 0.0 94:03 testu01long 2491 root 20 0 444m 128m 103m S 2 6.4 3.3 7:04 Xorg 2945 wolfgang 20 0 1950m 205m 11m S 2 6.4 5.4 13:08 cinnamon 1 root 20 0 27336 15360 S 1 0.0 0.0 0:01 init 2 root 20 0 000 S 3 0.0 0.0 0:00 kthreadd 3 root 20 0 000 S 0 0.0 0.0 0:00 ksoftirqd/0 5 root 0 -20 000 S 0 0.0 0.0 0:00
[Kernel-packages] [Bug 1308474] Re: CPU-intensive processes killed by OS
** Tags added: kernel-bug-reported-upstream -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1308474 Title: CPU-intensive processes killed by OS Status in “linux” package in Ubuntu: Triaged Bug description: When testing some algorithm I ran the test program several times with different parameters. It was to be expected that each run takes about four hours, and to utilize the capacities of my computer (4 CPUs) I started the program 4 times running in parallel and with lowered priority (the latter to be able to do meanwhile something else on the computer). All four processes ran in parallel for a few minutes but then two of them were killed with the error message: Command terminated by signal 9 [1] Exit 137/usr/bin/time -f '%U+%S sec, avg %Kk max %Mk memory, major %F minor %R faults, %I+%O i/o' ./testu01long -d9689 -b3 cat9689.tub Here, /usr/bin/time ... is the command I launched for the first process, the second error message was quite similar, now for the second process. The process started first ran about 6 minutes, the second about 14 minutes, so the TERM signals have been issued at different times (the processes had been started within one minute). The two other processes continued without problems. The point is that I did NOT issue a TERM signal to the processes, I conclude that the OS issued the TERM signals. The effect can be repeated to some extend: if another CPU-intensive process is started (e.g. a lengthy compilation) then an already running CPU-intensive process may be killed, if so then the one first started. When the killed program had been relaunched with the same parameters but without concurrency of other CPU-intensive processes (e.g. only editing, reading e-mails running in parallel) then all things were fine, so the kill is really not caused by the program. The program does not use external devices and even no I/O except for writing a summary to stdout at program end (i.e. not when the processes were killed). The question is, why have the processes been killed? Is the OS unable to manage as many running processes? I consider this a bug in the OS, part process management. The bug implies that the computer can be used for light weight tasks only. With regards Dr. Wolfgang Jansen PS: Additional platform info (commands ulimit -a, top when two CPU-intensive processes were still running): core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30092 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30092 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited --- Tasks: 244 total, 3 running, 241 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 1.2 sy, 27.5 ni, 54.6 id, 1.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3930376 total, 2263872 used, 1666504 free,36756 buffers KiB Swap: 9212 total, 9212 used,0 free, 705612 cached PID USER PR NI VIRT RES SHR S P %CPU %MEM TIME COMMAND 18804 wolfgang 30 10 14632 960 648 R 1 103.0 0.0 95:09 testu01long 18817 wolfgang 30 10 14632 960 648 R 0 103.0 0.0 94:03 testu01long 2491 root 20 0 444m 128m 103m S 2 6.4 3.3 7:04 Xorg 2945 wolfgang 20 0 1950m 205m 11m S 2 6.4 5.4 13:08 cinnamon 1 root 20 0 27336 15360 S 1 0.0 0.0 0:01 init 2 root 20 0 000 S 3 0.0 0.0 0:00 kthreadd 3 root 20 0 000 S 0 0.0 0.0 0:00 ksoftirqd/0 5 root 0 -20 000 S 0 0.0 0.0 0:00 kworker/0:0H 7 root rt 0 000 S 0 0.0 0.0 0:00 migration/0 8 root 20 0 000 S 0 0.0 0.0 0:00 rcu_bh 9 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/0 10 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/1 11 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/2 12 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/3 13 root 20 0 000 S 3 0.0 0.0 0:27 rcu_sched 14 root
[Kernel-packages] [Bug 1308474] Re: CPU-intensive processes killed by OS
apport information ** Tags added: apport-collected ** Description changed: When testing some algorithm I ran the test program several times with different parameters. It was to be expected that each run takes about four hours, and to utilize the capacities of my computer (4 CPUs) I started the program 4 times running in parallel and with lowered priority (the latter to be able to do meanwhile something else on the computer). All four processes ran in parallel for a few minutes but then two of them were killed with the error message: Command terminated by signal 9 [1] Exit 137/usr/bin/time -f '%U+%S sec, avg %Kk max %Mk memory, major %F minor %R faults, %I+%O i/o' ./testu01long -d9689 -b3 cat9689.tub Here, /usr/bin/time ... is the command I launched for the first process, the second error message was quite similar, now for the second process. The process started first ran about 6 minutes, the second about 14 minutes, so the TERM signals have been issued at different times (the processes had been started within one minute). The two other processes continued without problems. The point is that I did NOT issue a TERM signal to the processes, I conclude that the OS issued the TERM signals. The effect can be repeated to some extend: if another CPU-intensive process is started (e.g. a lengthy compilation) then an already running CPU-intensive process may be killed, if so then the one first started. When the killed program had been relaunched with the same parameters but without concurrency of other CPU-intensive processes (e.g. only editing, reading e-mails running in parallel) then all things were fine, so the kill is really not caused by the program. The program does not use external devices and even no I/O except for writing a summary to stdout at program end (i.e. not when the processes were killed). The question is, why have the processes been killed? Is the OS unable to manage as many running processes? I consider this a bug in the OS, part process management. The bug implies that the computer can be used for light weight tasks only. With regards Dr. Wolfgang Jansen PS: Additional platform info (commands ulimit -a, top when two CPU-intensive processes were still running): core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30092 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30092 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited --- Tasks: 244 total, 3 running, 241 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 1.2 sy, 27.5 ni, 54.6 id, 1.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3930376 total, 2263872 used, 1666504 free,36756 buffers KiB Swap: 9212 total, 9212 used,0 free, 705612 cached PID USER PR NI VIRT RES SHR S P %CPU %MEM TIME COMMAND 18804 wolfgang 30 10 14632 960 648 R 1 103.0 0.0 95:09 testu01long 18817 wolfgang 30 10 14632 960 648 R 0 103.0 0.0 94:03 testu01long 2491 root 20 0 444m 128m 103m S 2 6.4 3.3 7:04 Xorg 2945 wolfgang 20 0 1950m 205m 11m S 2 6.4 5.4 13:08 cinnamon 1 root 20 0 27336 15360 S 1 0.0 0.0 0:01 init 2 root 20 0 000 S 3 0.0 0.0 0:00 kthreadd 3 root 20 0 000 S 0 0.0 0.0 0:00 ksoftirqd/0 5 root 0 -20 000 S 0 0.0 0.0 0:00 kworker/0:0H 7 root rt 0 000 S 0 0.0 0.0 0:00 migration/0 8 root 20 0 000 S 0 0.0 0.0 0:00 rcu_bh 9 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/0 10 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/1 11 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/2 12 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/3 13 root 20 0 000 S 3 0.0 0.0 0:27 rcu_sched 14 root 20 0 000 S 3 0.0 0.0 0:06 rcuos/0 15 root 20 0 000 S 1 0.0 0.0 0:07 rcuos/1 Remark: The critical figure seems to be the swap space.
[Kernel-packages] [Bug 1308474] Re: CPU-intensive processes killed by OS
apport information ** Description changed: When testing some algorithm I ran the test program several times with different parameters. It was to be expected that each run takes about four hours, and to utilize the capacities of my computer (4 CPUs) I started the program 4 times running in parallel and with lowered priority (the latter to be able to do meanwhile something else on the computer). All four processes ran in parallel for a few minutes but then two of them were killed with the error message: Command terminated by signal 9 [1] Exit 137/usr/bin/time -f '%U+%S sec, avg %Kk max %Mk memory, major %F minor %R faults, %I+%O i/o' ./testu01long -d9689 -b3 cat9689.tub Here, /usr/bin/time ... is the command I launched for the first process, the second error message was quite similar, now for the second process. The process started first ran about 6 minutes, the second about 14 minutes, so the TERM signals have been issued at different times (the processes had been started within one minute). The two other processes continued without problems. The point is that I did NOT issue a TERM signal to the processes, I conclude that the OS issued the TERM signals. The effect can be repeated to some extend: if another CPU-intensive process is started (e.g. a lengthy compilation) then an already running CPU-intensive process may be killed, if so then the one first started. When the killed program had been relaunched with the same parameters but without concurrency of other CPU-intensive processes (e.g. only editing, reading e-mails running in parallel) then all things were fine, so the kill is really not caused by the program. The program does not use external devices and even no I/O except for writing a summary to stdout at program end (i.e. not when the processes were killed). The question is, why have the processes been killed? Is the OS unable to manage as many running processes? I consider this a bug in the OS, part process management. The bug implies that the computer can be used for light weight tasks only. With regards Dr. Wolfgang Jansen PS: Additional platform info (commands ulimit -a, top when two CPU-intensive processes were still running): core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30092 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30092 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited --- Tasks: 244 total, 3 running, 241 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 1.2 sy, 27.5 ni, 54.6 id, 1.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3930376 total, 2263872 used, 1666504 free,36756 buffers KiB Swap: 9212 total, 9212 used,0 free, 705612 cached PID USER PR NI VIRT RES SHR S P %CPU %MEM TIME COMMAND 18804 wolfgang 30 10 14632 960 648 R 1 103.0 0.0 95:09 testu01long 18817 wolfgang 30 10 14632 960 648 R 0 103.0 0.0 94:03 testu01long 2491 root 20 0 444m 128m 103m S 2 6.4 3.3 7:04 Xorg 2945 wolfgang 20 0 1950m 205m 11m S 2 6.4 5.4 13:08 cinnamon 1 root 20 0 27336 15360 S 1 0.0 0.0 0:01 init 2 root 20 0 000 S 3 0.0 0.0 0:00 kthreadd 3 root 20 0 000 S 0 0.0 0.0 0:00 ksoftirqd/0 5 root 0 -20 000 S 0 0.0 0.0 0:00 kworker/0:0H 7 root rt 0 000 S 0 0.0 0.0 0:00 migration/0 8 root 20 0 000 S 0 0.0 0.0 0:00 rcu_bh 9 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/0 10 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/1 11 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/2 12 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/3 13 root 20 0 000 S 3 0.0 0.0 0:27 rcu_sched 14 root 20 0 000 S 3 0.0 0.0 0:06 rcuos/0 15 root 20 0 000 S 1 0.0 0.0 0:07 rcuos/1 Remark: The critical figure seems to be the swap space. ProblemType: Bug DistroRelease: Ubuntu
Re: [Kernel-packages] [Bug 1308474] Re: CPU-intensive processes killed by OS
On 04/16/2014 09:36 PM, Joseph Salisbury wrote: Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.15 kernel[0]. If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'. If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'. If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. Once testing of the upstream kernel is complete, please mark this bug as Confirmed. Thanks in advance. [0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc1-trusty/ ** Changed in: linux (Ubuntu) Importance: Undecided = Medium ** Tags added: kernel-da-key Sorry, I did not find a specific field to add a tag, so I added a comment, right? WJ -- Dr. Wolfgang Jansen Lauenburger Straße 40 D-12169 Berlin Tel: (+49) 0172 40 86 916 e-mail: wo.jan...@kabelmail.de -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1308474 Title: CPU-intensive processes killed by OS Status in “linux” package in Ubuntu: Confirmed Bug description: When testing some algorithm I ran the test program several times with different parameters. It was to be expected that each run takes about four hours, and to utilize the capacities of my computer (4 CPUs) I started the program 4 times running in parallel and with lowered priority (the latter to be able to do meanwhile something else on the computer). All four processes ran in parallel for a few minutes but then two of them were killed with the error message: Command terminated by signal 9 [1] Exit 137/usr/bin/time -f '%U+%S sec, avg %Kk max %Mk memory, major %F minor %R faults, %I+%O i/o' ./testu01long -d9689 -b3 cat9689.tub Here, /usr/bin/time ... is the command I launched for the first process, the second error message was quite similar, now for the second process. The process started first ran about 6 minutes, the second about 14 minutes, so the TERM signals have been issued at different times (the processes had been started within one minute). The two other processes continued without problems. The point is that I did NOT issue a TERM signal to the processes, I conclude that the OS issued the TERM signals. The effect can be repeated to some extend: if another CPU-intensive process is started (e.g. a lengthy compilation) then an already running CPU-intensive process may be killed, if so then the one first started. When the killed program had been relaunched with the same parameters but without concurrency of other CPU-intensive processes (e.g. only editing, reading e-mails running in parallel) then all things were fine, so the kill is really not caused by the program. The program does not use external devices and even no I/O except for writing a summary to stdout at program end (i.e. not when the processes were killed). The question is, why have the processes been killed? Is the OS unable to manage as many running processes? I consider this a bug in the OS, part process management. The bug implies that the computer can be used for light weight tasks only. With regards Dr. Wolfgang Jansen PS: Additional platform info (commands ulimit -a, top when two CPU-intensive processes were still running): core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30092 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30092 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited --- Tasks: 244 total, 3 running, 241 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 1.2 sy, 27.5 ni, 54.6 id, 1.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3930376 total, 2263872 used, 1666504 free,36756 buffers KiB Swap: 9212 total, 9212 used,0 free, 705612 cached PID USER PR NI VIRT RES SHR S P %CPU %MEM TIME COMMAND 18804 wolfgang 30 10 14632 960 648 R 1 103.0 0.0 95:09 testu01long 18817 wolfgang 30 10 14632 960 648 R 0 103.0 0.0 94:03 testu01long 2491 root 20 0 444m 128m 103m S 2 6.4 3.3 7:04 Xorg 2945 wolfgang 20 0
[Kernel-packages] [Bug 1308474] Re: CPU-intensive processes killed by OS
kernel-bug-exists-upstream -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1308474 Title: CPU-intensive processes killed by OS Status in “linux” package in Ubuntu: Confirmed Bug description: When testing some algorithm I ran the test program several times with different parameters. It was to be expected that each run takes about four hours, and to utilize the capacities of my computer (4 CPUs) I started the program 4 times running in parallel and with lowered priority (the latter to be able to do meanwhile something else on the computer). All four processes ran in parallel for a few minutes but then two of them were killed with the error message: Command terminated by signal 9 [1] Exit 137/usr/bin/time -f '%U+%S sec, avg %Kk max %Mk memory, major %F minor %R faults, %I+%O i/o' ./testu01long -d9689 -b3 cat9689.tub Here, /usr/bin/time ... is the command I launched for the first process, the second error message was quite similar, now for the second process. The process started first ran about 6 minutes, the second about 14 minutes, so the TERM signals have been issued at different times (the processes had been started within one minute). The two other processes continued without problems. The point is that I did NOT issue a TERM signal to the processes, I conclude that the OS issued the TERM signals. The effect can be repeated to some extend: if another CPU-intensive process is started (e.g. a lengthy compilation) then an already running CPU-intensive process may be killed, if so then the one first started. When the killed program had been relaunched with the same parameters but without concurrency of other CPU-intensive processes (e.g. only editing, reading e-mails running in parallel) then all things were fine, so the kill is really not caused by the program. The program does not use external devices and even no I/O except for writing a summary to stdout at program end (i.e. not when the processes were killed). The question is, why have the processes been killed? Is the OS unable to manage as many running processes? I consider this a bug in the OS, part process management. The bug implies that the computer can be used for light weight tasks only. With regards Dr. Wolfgang Jansen PS: Additional platform info (commands ulimit -a, top when two CPU-intensive processes were still running): core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 30092 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 30092 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited --- Tasks: 244 total, 3 running, 241 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 1.2 sy, 27.5 ni, 54.6 id, 1.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3930376 total, 2263872 used, 1666504 free,36756 buffers KiB Swap: 9212 total, 9212 used,0 free, 705612 cached PID USER PR NI VIRT RES SHR S P %CPU %MEM TIME COMMAND 18804 wolfgang 30 10 14632 960 648 R 1 103.0 0.0 95:09 testu01long 18817 wolfgang 30 10 14632 960 648 R 0 103.0 0.0 94:03 testu01long 2491 root 20 0 444m 128m 103m S 2 6.4 3.3 7:04 Xorg 2945 wolfgang 20 0 1950m 205m 11m S 2 6.4 5.4 13:08 cinnamon 1 root 20 0 27336 15360 S 1 0.0 0.0 0:01 init 2 root 20 0 000 S 3 0.0 0.0 0:00 kthreadd 3 root 20 0 000 S 0 0.0 0.0 0:00 ksoftirqd/0 5 root 0 -20 000 S 0 0.0 0.0 0:00 kworker/0:0H 7 root rt 0 000 S 0 0.0 0.0 0:00 migration/0 8 root 20 0 000 S 0 0.0 0.0 0:00 rcu_bh 9 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/0 10 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/1 11 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/2 12 root 20 0 000 S 0 0.0 0.0 0:00 rcuob/3 13 root 20 0 000 S 3 0.0 0.0 0:27 rcu_sched 14 root 20 0
