Re: Shell-Script problems
Henrik Wallin (henrik@triton.campus.luth.se)
Sat, 7 Dec 1996 22:16:30 +0100 (MET)
On Sat, 7 Dec 1996, Erik Andersen wrote:
>
> On Dec 7, 1996 16:07:31 +0000, Meino Christian Cramer wrote:
> >
> > High!
> >
> > I've got strange things while trying to execute a shell script...
> >
>
> [----------- snip, snip, snip -----------]
>
> >
> > Because some days ago one mentioned another problem while
> > executing scripts with "!/bin/sh -" (I have got the same problem
> > while executing MAKEDEV), may be this is a error of the same kind?
> >
>
> That was me, and I am STILL having some wierd script problems under 2.1.14.
> The following is taken directly from an xterm running bash under 2.0.27,
> and demonstrates the correct behavior:
>
> andersee@Dillweed% cat scum
> #!/bin/bash
> # A useless script named scum
> until [ -e /tmp/foo_does_not_exist ] ;do
> sleep 1
> done
>
> andersee@Dillweed% scum &
> [1] 1027
> andersee@Dillweed% type ps
> ps is aliased to `ps -acux '
> andersee@Dillweed% ps | grep scum
> andersee 1027 0.1 4.1 1396 616 p1 S 12:50 0:00 scum
> andersee@Dillweed% uname -a
> Linux Dillweed 2.0.27 #1 Sun Dec 1 13:06:32 MST 1996 i486
> andersee@Dillweed% touch /tmp/foo_does_not_exist
> [1]+ Done scum
> andersee@Dillweed%
>
>
> This is all correct! No problems at all. But now, I simply reboot into
> kernel 2.1.14 (no other changes whatsoever) and I now get:
>
>
> andersee@Dillweed% scum &
> [1] 282
> andersee@Dillweed% ps | grep scum
> andersee@Dillweed% killall scum
> scum: no process killed
> andersee@Dillweed% touch /tmp/foo_does_not_exist
> [1]+ Done scum
> andersee@Dillweed% uname -a
> Linux Dillweed 2.1.14 #3 Sun Dec 1 17:50:36 MST 1996 i486
> andersee@Dillweed% cat /etc/issue
> Debian GNU/Linux 1.2
> Copyright (C) 1993-1996 Software in the Public Interest, Inc. and others
> andersee@Dillweed% bash -version
> GNU bash, version 1.14.7(1)
> andersee@Dillweed% ldd `which bash`
> libreadline.so.2.0 => /lib/libreadline.so.2.0.1
> libncurses.so.3.0 => /lib/libncurses.so.3.0
> libc.so.5 => /lib/libc.so.5.4.13
> andersee@Dillweed% ps --version
> procps version 1.11
> andersee@Dillweed% ldd `which ps`
> libproc.so.1.11 => /lib/libproc.so.1.11
> libc.so.5 => /lib/libc.so.5.4.13
> andersee@Dillweed% grep -V
> GNU grep version 2.0
> usage: grep [-[[AB] ]<num>] [-[CEFGVchilnqsvwx]] [-[ef]] <expr> [<files...>]
> andersee@Dillweed% ldd `which grep`
> libc.so.5 => /lib/libc.so.5.4.13
> andersee@Dillweed%
>
>
> Something is wrong here. This script does not show up under the ps
> listing. The only change between 2.0.27, where it worked correctly, and
> 2.1.14, where the behavior is broken is that I rebooted to load the new
> kernel. If I reboot into 2.0.27, it works again. Please try this script
> using the same version of bash and ps and I believe you will see the same
> error. If I am somehow using an old version of something, please let me
> know. If you don't see something you want, just ask.
>
> This is a live bug, and it seems related to the recent changes in how the
> kernel runs scripts. I sent an earlier post about this, but I was not very
> precise.
>
> -Erik
>
> --
> Erik B. Andersen Web: http://www.et.byu.edu/~andersee/
> 2485 South State St. email: andersee@et.byu.edu or andersee@debian.org
> Springville, Ut 84663 phone: (801) 489-1231
> --This message was written using 73% post-consumer electrons--
>
Hi,
I think this is caused by ps and/or killall.
Don't know if it is a bug in ps or not though.
Maybe something has changed in some struct in kernel that psutils must
'be teached' about?
henrik@triton ~ > ./scum &
[1] 2987
henrik@triton ~ > ps -acux | grep scum
henrik@triton ~ > killall scum
scum: no process killed
henrik@triton ~ > ps -aux | grep scum
henrik 2987 0.3 1.3 1396 624 p7 S 21:56 0:00 bash ./scum
henrik 3012 0.0 0.6 888 300 p7 S 21:57 0:00 grep scum
henrik@triton ~ > touch /tmp/foo_does_not_exist
henrik@triton ~ >
[1]+ Done ./scum
henrik@triton ~ >
GNU bash, version 1.14.7(1)
procps version 1.11
GNU grep version 2.0
killall from psmisc version 12
Another thing about ps is that when you redirects the output from ps
to something other than stdout it seems that 'ps' just outputs the
first 80 characters per line.
Compare 'ps -aux | more' with 'ps -auxwww | more'.
I would prefer unlimited line-length in this case.
/ Henrik W, henrik@triton.campus.luth.se