100% cpu with: while true ;do read < /dev/null ;done

[Jo King]

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]

[Jan Schampera]

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

[Mike Frysinger]

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

[Pierre Gaston]

On Thu, Oct 22, 2009 at 12:15 AM, Jo King <jokiiii@...> 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

[Jo King]

> 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.gaston@...> wrote:

> From: Pierre Gaston <pierre.gaston@...>
> Subject: Re: 100% cpu with: while true ;do read < /dev/null ;done
> To: "Jo King" <jokiiii@...>
> Cc: bug-bash@...
> Date: Thursday, 22 October, 2009, 7:08
>
>
> On Thu, Oct 22, 2009 at 12:15 AM,
> Jo King <jokiiii@...>
> 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
>
>

[Marc Herbert-5]

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