Re: 100% cpu with: while true ;do read /dev/null ;done
Jo King a écrit : thanks for reply. agree it's not a bug with bash. i am inclinded to agree with the comments but bash is popular and attracts a lot of newbies into scripting - a bit of smart 'correction' of their wrong ways would at least keep the cpu available for other processes (even a sleep for 100ms would make a huge difference). Newbies should just stay clear from developing any advanced shell script. There is way too much rope too hang themselves and your example is just one among many other ways. There is plenty other, newer programming environments that are far easier and safer to play with and learn. By the way the same hold for configuring firewalls. It becomes even worse when it relates to security. (Security by newbies... ahem, really?) Cheers, Marc
Re: 100% cpu with: while true ;do read /dev/null ;done
On Thu, Oct 22, 2009 at 12:15 AM, Jo King joki...@yahoo.co.uk wrote: Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux puppypc 2.6.30.5 #1 SMP Tue Sep 1 15:48:26 GMT-8 2009 i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 48 Release Status: release Description: [See subject for test case. Many scripts sit in a loop asking for user input - if script is run in bg/without tty (by mistake) then high cpu usage results] Repeat-By: [while true ;do read /dev/null ;done] Fix: [ bash/the read code could detect there's no stdin and sleep for 1-2 seconds] Script waiting for user input in the background will be stopped on read, and it will not result in a busy loop. A script that expects a tty should test it with something like: if ! [ -t 0 ]; then echo this script must be run in a terminal; exit 1;fi I too believe that the scripts must be fixed, not bash
Re: 100% cpu with: while true ;do read /dev/null ;done
thanks for reply. agree it's not a bug with bash. i am inclinded to agree with the comments but bash is popular and attracts a lot of newbies into scripting - a bit of smart 'correction' of their wrong ways would at least keep the cpu available for other processes (even a sleep for 100ms would make a huge difference). for info the script is firelog (network/firewall frontend) - written by a non-advanced bash coder, though i have come across similar with ksh on solaris/aix in the past. --- On Thu, 22/10/09, Pierre Gaston pierre.gas...@gmail.com wrote: From: Pierre Gaston pierre.gas...@gmail.com Subject: Re: 100% cpu with: while true ;do read /dev/null ;done To: Jo King joki...@yahoo.co.uk Cc: bug-bash@gnu.org Date: Thursday, 22 October, 2009, 7:08 On Thu, Oct 22, 2009 at 12:15 AM, Jo King joki...@yahoo.co.uk wrote: Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux puppypc 2.6.30.5 #1 SMP Tue Sep 1 15:48:26 GMT-8 2009 i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 48 Release Status: release Description: [See subject for test case. Many scripts sit in a loop asking for user input - if script is run in bg/without tty (by mistake) then high cpu usage results] Repeat-By: [while true ;do read /dev/null ;done] Fix: [ bash/the read code could detect there's no stdin and sleep for 1-2 seconds] Script waiting for user input in the background will be stopped on read, and it will not result in a busy loop. A script that expects a tty should test it with something like: if ! [ -t 0 ]; then echo this script must be run in a terminal; exit 1;fi I too believe that the scripts must be fixed, not bash
100% cpu with: while true ;do read /dev/null ;done
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux puppypc 2.6.30.5 #1 SMP Tue Sep 1 15:48:26 GMT-8 2009 i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 48 Release Status: release Description: [See subject for test case. Many scripts sit in a loop asking for user input - if script is run in bg/without tty (by mistake) then high cpu usage results] Repeat-By: [while true ;do read /dev/null ;done] Fix: [ bash/the read code could detect there's no stdin and sleep for 1-2 seconds]
Re: 100% cpu with: while true ;do read /dev/null ;done
Jo King schrieb: Fix: [ bash/the read code could detect there's no stdin and sleep for 1-2 seconds] If you consider this as a bug, the bug is not in Bash (but in the application). In short you request that read should wait a second, once it got a end-of-file signalled, I don't think this is the way to 'fix' this 'bug'. It has far too many side effects or impacts to other uses of read. Fix your application instead, query the exit code of read (non-zero on EOF, timeout or error) and insert a conditional sleep yourself. By the way (not really serious, but it fits): A CPU constantly below 100% is wasted money ;-) Jan
Re: 100% cpu with: while true ;do read /dev/null ;done
On Thursday 22 October 2009 01:10:33 Jan Schampera wrote: Jo King schrieb: Fix: [ bash/the read code could detect there's no stdin and sleep for 1-2 seconds] If you consider this as a bug, the bug is not in Bash (but in the application). In short you request that read should wait a second, once it got a end-of-file signalled, I don't think this is the way to 'fix' this 'bug'. It has far too many side effects or impacts to other uses of read. Fix your application instead, query the exit code of read (non-zero on EOF, timeout or error) and insert a conditional sleep yourself. and the code can easily be fixed b adding -t 1 to the read invocation -mike signature.asc Description: This is a digitally signed message part.
