Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, 18 Sep 2011 07:39:01 +0200, Jeremy Chadwick
free...@jdc.parodius.com wrote:
On Sun, Sep 18, 2011 at 12:54:13AM -0400, Jason Hellenthal wrote:
On Sun, Sep 18, 2011 at 01:49:15AM +0200, Ronald Klop wrote:
Hi,
I'm running portupgrade in screen to update all the ports for
9-BETA2/9-CURRENT on amd64. While doing this script eats 100% cpu.
Because portupgrade -fa crashed I'm running this command to update the
remaining non-updates ports.
find /var/db/pkg -name +DESC -mtime +2 |cut -d / -f 5 | xargs time
nice -n
20 portupgrade -f
The output of truss -p `pgrep script` is this:
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
So it is really fast in reading and writing 0 bytes most of the time.
I also found
http://web.archiveorange.com/archive/v/6ETvLvjo60Gj9geAUAb6
and I think I am better of by rewriting my command so stdin/stdout is
still the terminal. Although the link is a couple of years old.
Is this known? Can somebody explain me why my xargs command is not
working
well?
Are you absolutely sure that its script(1) causing this ? 100% CPU usage
has been a known side effect of screen(1) for quite some time. Rebuild
it and try again.
Jason's referring to this, I believe:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.55
To clarify the what the commit message means: it does not mean when the
package is installed the installation takes up 100% CPU. It means
once the package is installed and screen is used, screen takes up 100%
CPU. I know because I've seen this behaviour in the past (one of the
many, many reasons I build ports from source).
However:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.78
So: If a binary package is being installed through your above
portupgrade command, and you're seeing this problem, then it sounds to
me like commit revision 1.78 is a regression and NO_PACKAGE should be
put back into place + packages removed from all mirrors.
There are many reasons to not use GNU screen at all, or if you must have
something like it, use tmux. I recently had to provide an analysis of
how GNU screen destroys one's terminal[1]; so if the above problem turns
out to be caused by GNU screen as well, I'll just add it to my
ever-growing list of reasons the software should be nuked from orbit.
Otherwise, if this turns out to be a problem with portupgrade (which you
found some evidence supporting such), then the solution is simple: stop
using portupgrade, use portmaster (if it lacks things you need ask Doug
Barton, he's incredibly receptive to adding new features/fixing things).
Two databases that aren't compatible, ruby shims, and other crap = not
worth it. Think the database ordeal is long over with/fixed/whatever?
It isn't[2].
[1]:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html
[2]:
http://www.dslreports.com/forum/r26304856-FreeBSD-defining-portmaster-alias
I have a repeatable test. Run top in a window and this command in another.
$ echo test | script /tmp/script-test sleep 1000
Script started, output file is /tmp/script-test
test
PID USERNAME THR PRI NICE SIZERES STATE C TIMECPU
COMMAND
29656 ronald 1 1030 12324K 1244K CPU44 1:03 100.00%
script
So it has nothing to do with portupgrade or screen. The output of truss
-p29656 is the same as posted previously.
Ronald.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, Sep 18, 2011 at 08:47:13AM +0200, Ronald Klop wrote:
On Sun, 18 Sep 2011 07:39:01 +0200, Jeremy Chadwick
free...@jdc.parodius.com wrote:
On Sun, Sep 18, 2011 at 12:54:13AM -0400, Jason Hellenthal wrote:
On Sun, Sep 18, 2011 at 01:49:15AM +0200, Ronald Klop wrote:
Hi,
I'm running portupgrade in screen to update all the ports for
9-BETA2/9-CURRENT on amd64. While doing this script eats 100% cpu.
Because portupgrade -fa crashed I'm running this command to update the
remaining non-updates ports.
find /var/db/pkg -name +DESC -mtime +2 |cut -d / -f 5 | xargs
time nice -n
20 portupgrade -f
The output of truss -p `pgrep script` is this:
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
So it is really fast in reading and writing 0 bytes most of the time.
I also found
http://web.archiveorange.com/archive/v/6ETvLvjo60Gj9geAUAb6
and I think I am better of by rewriting my command so stdin/stdout is
still the terminal. Although the link is a couple of years old.
Is this known? Can somebody explain me why my xargs command is
not working
well?
Are you absolutely sure that its script(1) causing this ? 100% CPU usage
has been a known side effect of screen(1) for quite some time. Rebuild
it and try again.
Jason's referring to this, I believe:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.55
To clarify the what the commit message means: it does not mean when the
package is installed the installation takes up 100% CPU. It means
once the package is installed and screen is used, screen takes up 100%
CPU. I know because I've seen this behaviour in the past (one of the
many, many reasons I build ports from source).
However:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.78
So: If a binary package is being installed through your above
portupgrade command, and you're seeing this problem, then it sounds to
me like commit revision 1.78 is a regression and NO_PACKAGE should be
put back into place + packages removed from all mirrors.
There are many reasons to not use GNU screen at all, or if you must have
something like it, use tmux. I recently had to provide an analysis of
how GNU screen destroys one's terminal[1]; so if the above problem turns
out to be caused by GNU screen as well, I'll just add it to my
ever-growing list of reasons the software should be nuked from orbit.
Otherwise, if this turns out to be a problem with portupgrade (which you
found some evidence supporting such), then the solution is simple: stop
using portupgrade, use portmaster (if it lacks things you need ask Doug
Barton, he's incredibly receptive to adding new features/fixing things).
Two databases that aren't compatible, ruby shims, and other crap = not
worth it. Think the database ordeal is long over with/fixed/whatever?
It isn't[2].
[1]: http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html
[2]:
http://www.dslreports.com/forum/r26304856-FreeBSD-defining-portmaster-alias
I have a repeatable test. Run top in a window and this command in another.
$ echo test | script /tmp/script-test sleep 1000
Script started, output file is /tmp/script-test
test
PID USERNAME THR PRI NICE SIZERES STATE C TIME
CPU COMMAND
29656 ronald 1 1030 12324K 1244K CPU44 1:03
100.00% script
So it has nothing to do with portupgrade or screen. The output of
truss -p29656 is the same as posted previously.
Good deal.
I can reproduce this problem too, on RELENG_8 dated 2011/09/16. I
haven't tried older FreeBSD releases.
$ echo test | script /tmp/script-test sleep 1000
Script started, output file is /tmp/script-test
test
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
33803 jdc 1 1140 7020K 1236K CPU11 0:22 79.98% script
/tmp/script-test sleep 1000
Relevant fstat to examine fds:
# fstat -p 33803
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
jdc script 33803 root
Re: CARP interfaces and mastership issue
Le Sat, 17 Sep 2011 23:40:06 -0400 (EDT), Brian Seklecki (Mobile) laval...@probikesllc.com a écrit : What would help here, is for a carp interface to wait a given delay (tunable through a sysctl ?) after creation or after being brought up I see now. The tunable sounds like a good idea; we should check OpenBSD, they probably already implemented something and we're behind. If not, a preempt dampener feature would be an awesome return feature. Might need to implment another state: MASTER-LISTENING (or LEARNING) ah a STP. OpenBSD uses a carp demote counter that prevents to become master (but it will become master anyway if there is not carp advertizement on the interface). There is a sysctl in FreeBSD but it's readonly. This is used to delay carp until pfsync synchronization is done and by daemons like bgpd. Anyway if carp becomes master when the interface is set up, it looks to be a bug on FreeBSD (and if you are sure that the problem does not come from the switch). That works fine on OpenBSD. Regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, 18 Sep 2011 12:58:32 +0200, Mikolaj Golub troc...@freebsd.org
wrote:
On Sun, 18 Sep 2011 08:47:13 +0200 Ronald Klop wrote:
RK On Sun, 18 Sep 2011 07:39:01 +0200, Jeremy Chadwick
RK free...@jdc.parodius.com wrote:
On Sun, Sep 18, 2011 at 12:54:13AM -0400, Jason Hellenthal wrote:
On Sun, Sep 18, 2011 at 01:49:15AM +0200, Ronald Klop wrote:
Hi,
I'm running portupgrade in screen to update all the ports for
9-BETA2/9-CURRENT on amd64. While doing this script eats 100% cpu.
Because portupgrade -fa crashed I'm running this command to
update the
remaining non-updates ports.
find /var/db/pkg -name +DESC -mtime +2 |cut -d / -f 5 | xargs
time nice -n
20 portupgrade -f
The output of truss -p `pgrep script` is this:
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
So it is really fast in reading and writing 0 bytes most of the
time.
I also found
http://web.archiveorange.com/archive/v/6ETvLvjo60Gj9geAUAb6
and I think I am better of by rewriting my command so
stdin/stdout is
still the terminal. Although the link is a couple of years old.
Is this known? Can somebody explain me why my xargs command is
not working
well?
Are you absolutely sure that its script(1) causing this ? 100% CPU
usage
has been a known side effect of screen(1) for quite some time.
Rebuild
it and try again.
Jason's referring to this, I believe:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.55
To clarify the what the commit message means: it does not mean when
the
package is installed the installation takes up 100% CPU. It means
once the package is installed and screen is used, screen takes up
100%
CPU. I know because I've seen this behaviour in the past (one of
the
many, many reasons I build ports from source).
However:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.78
So: If a binary package is being installed through your above
portupgrade command, and you're seeing this problem, then it sounds
to
me like commit revision 1.78 is a regression and NO_PACKAGE should be
put back into place + packages removed from all mirrors.
There are many reasons to not use GNU screen at all, or if you must
have
something like it, use tmux. I recently had to provide an analysis
of
how GNU screen destroys one's terminal[1]; so if the above problem
turns
out to be caused by GNU screen as well, I'll just add it to my
ever-growing list of reasons the software should be nuked from orbit.
Otherwise, if this turns out to be a problem with portupgrade (which
you
found some evidence supporting such), then the solution is simple:
stop
using portupgrade, use portmaster (if it lacks things you need ask
Doug
Barton, he's incredibly receptive to adding new features/fixing
things).
Two databases that aren't compatible, ruby shims, and other crap =
not
worth it. Think the database ordeal is long over
with/fixed/whatever?
It isn't[2].
[1]:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html
[2]:
http://www.dslreports.com/forum/r26304856-FreeBSD-defining-portmaster-alias
RK I have a repeatable test. Run top in a window and this command in
another.
RK $ echo test | script /tmp/script-test sleep 1000
RK Script started, output file is /tmp/script-test
RK test
RK PID USERNAME THR PRI NICE SIZERES STATE C TIME
RK CPU COMMAND
RK 29656 ronald 1 1030 12324K 1244K CPU44 1:03
RK 100.00% script
RK So it has nothing to do with portupgrade or screen. The output of
RK truss -p29656 is the same as posted previously.
I believe the behaviour is after this commit:
http://svnweb.freebsd.org/base?view=revisionrevision=125848
I think we should skip select on STDIN after reading EOF from it, like
in the
patch below.
It is a while since I programmed C, but why will writing 0 bytes give the
reader an end-of-file?
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, 18 Sep 2011 08:47:13 +0200 Ronald Klop wrote:
RK On Sun, 18 Sep 2011 07:39:01 +0200, Jeremy Chadwick
RK free...@jdc.parodius.com wrote:
On Sun, Sep 18, 2011 at 12:54:13AM -0400, Jason Hellenthal wrote:
On Sun, Sep 18, 2011 at 01:49:15AM +0200, Ronald Klop wrote:
Hi,
I'm running portupgrade in screen to update all the ports for
9-BETA2/9-CURRENT on amd64. While doing this script eats 100% cpu.
Because portupgrade -fa crashed I'm running this command to update the
remaining non-updates ports.
find /var/db/pkg -name +DESC -mtime +2 |cut -d / -f 5 | xargs
time nice -n
20 portupgrade -f
The output of truss -p `pgrep script` is this:
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
clock_gettime(13,{1316301104.0 })= 0 (0x0)
select(5,{0 4},0x0,0x0,{30.00 }) = 1 (0x1)
read(0,0x7fffcdf0,1024) = 0 (0x0)
write(4,0x7fffcdf0,0)= 0 (0x0)
So it is really fast in reading and writing 0 bytes most of the time.
I also found
http://web.archiveorange.com/archive/v/6ETvLvjo60Gj9geAUAb6
and I think I am better of by rewriting my command so stdin/stdout is
still the terminal. Although the link is a couple of years old.
Is this known? Can somebody explain me why my xargs command is
not working
well?
Are you absolutely sure that its script(1) causing this ? 100% CPU usage
has been a known side effect of screen(1) for quite some time. Rebuild
it and try again.
Jason's referring to this, I believe:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.55
To clarify the what the commit message means: it does not mean when the
package is installed the installation takes up 100% CPU. It means
once the package is installed and screen is used, screen takes up 100%
CPU. I know because I've seen this behaviour in the past (one of the
many, many reasons I build ports from source).
However:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/screen/Makefile#rev1.78
So: If a binary package is being installed through your above
portupgrade command, and you're seeing this problem, then it sounds to
me like commit revision 1.78 is a regression and NO_PACKAGE should be
put back into place + packages removed from all mirrors.
There are many reasons to not use GNU screen at all, or if you must have
something like it, use tmux. I recently had to provide an analysis of
how GNU screen destroys one's terminal[1]; so if the above problem turns
out to be caused by GNU screen as well, I'll just add it to my
ever-growing list of reasons the software should be nuked from orbit.
Otherwise, if this turns out to be a problem with portupgrade (which you
found some evidence supporting such), then the solution is simple: stop
using portupgrade, use portmaster (if it lacks things you need ask Doug
Barton, he's incredibly receptive to adding new features/fixing things).
Two databases that aren't compatible, ruby shims, and other crap = not
worth it. Think the database ordeal is long over with/fixed/whatever?
It isn't[2].
[1]:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html
[2]:
http://www.dslreports.com/forum/r26304856-FreeBSD-defining-portmaster-alias
RK I have a repeatable test. Run top in a window and this command in another.
RK $ echo test | script /tmp/script-test sleep 1000
RK Script started, output file is /tmp/script-test
RK test
RK PID USERNAME THR PRI NICE SIZERES STATE C TIME
RK CPU COMMAND
RK 29656 ronald 1 1030 12324K 1244K CPU44 1:03
RK 100.00% script
RK So it has nothing to do with portupgrade or screen. The output of
RK truss -p29656 is the same as posted previously.
I believe the behaviour is after this commit:
http://svnweb.freebsd.org/base?view=revisionrevision=125848
I think we should skip select on STDIN after reading EOF from it, like in the
patch below.
--
Mikolaj Golub
Index: usr.bin/script/script.c
===
--- usr.bin/script/script.c (revision 225648)
+++ usr.bin/script/script.c (working copy)
@@ -53,6 +53,7 @@ static const char sccsid[] =
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, 18 Sep 2011 13:25:26 +0200 Ronald Klop wrote: RK It is a while since I programmed C, but why will writing 0 bytes give RK the reader an end-of-file? Shouldn't the fd be closed to indicate RK end-of-file? AFAIR, this trick with writing 0 to emulate EOF because we can't close the fd -- we still want to read from it. Poor shutdown(2) for non-socket :-). Colin might tell more... -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARP interfaces and mastership issue
On 18 Sep 2011, at 12:44, Patrick Lamaiziere patf...@davenulle.org wrote: Le Sat, 17 Sep 2011 23:40:06 -0400 (EDT), Brian Seklecki (Mobile) laval...@probikesllc.com a écrit : What would help here, is for a carp interface to wait a given delay (tunable through a sysctl ?) after creation or after being brought up I see now. The tunable sounds like a good idea; we should check OpenBSD, they probably already implemented something and we're behind. If not, a preempt dampener feature would be an awesome return feature. Might need to implment another state: MASTER-LISTENING (or LEARNING) ah a STP. OpenBSD uses a carp demote counter that prevents to become master (but it will become master anyway if there is not carp advertizement on the interface). There is a sysctl in FreeBSD but it's readonly. This is used to delay carp until pfsync synchronization is done and by daemons like bgpd. Anyway if carp becomes master when the interface is set up, it looks to be a bug on FreeBSD (and if you are sure that the problem does not come from the switch). This can be easily verified. When our vlan13 is forwarding on the switch, destroy and recreate the carp13 interface. It still assumes mastership during a short time, then yields and becomes backup.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, Sep 18, 2011 at 02:54:34PM +0300, Mikolaj Golub wrote: On Sun, 18 Sep 2011 13:25:26 +0200 Ronald Klop wrote: RK It is a while since I programmed C, but why will writing 0 bytes give RK the reader an end-of-file? Shouldn't the fd be closed to indicate RK end-of-file? AFAIR, this trick with writing 0 to emulate EOF because we can't close the fd -- we still want to read from it. Poor shutdown(2) for non-socket :-). Colin might tell more... Please note that interpreting the receiving of 0 bytes on the terminal as EOF is only a convention. If done absolutely properly, script shall not interpret zero-byte read as EOF. Might be, the reasonable thing to do would be to only look at the stdin once in a second after receiving zero-bytes, and switching it back to normal mode if something is read. pgpHt3LnC7dhH.pgp Description: PGP signature
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, 18 Sep 2011 20:24:23 +0300 Kostik Belousov wrote:
KB On Sun, Sep 18, 2011 at 02:54:34PM +0300, Mikolaj Golub wrote:
On Sun, 18 Sep 2011 13:25:26 +0200 Ronald Klop wrote:
RK It is a while since I programmed C, but why will writing 0 bytes give
RK the reader an end-of-file? Shouldn't the fd be closed to indicate
RK end-of-file?
AFAIR, this trick with writing 0 to emulate EOF because we can't close the
fd
-- we still want to read from it. Poor shutdown(2) for non-socket :-).
Colin might tell more...
KB Please note that interpreting the receiving of 0 bytes on the terminal
KB as EOF is only a convention. If done absolutely properly, script shall
KB not interpret zero-byte read as EOF. Might be, the reasonable thing to
KB do would be to only look at the stdin once in a second after receiving
KB zero-bytes, and switching it back to normal mode if something is read.
Ok. I see. Below is the patch that does something like this.
--
Mikolaj Golub
Index: usr.bin/script/script.c
===
--- usr.bin/script/script.c (revision 225653)
+++ usr.bin/script/script.c (working copy)
@@ -53,6 +53,7 @@ static const char sccsid[] = @(#)script.c 8.1 (Be
#include libutil.h
#include paths.h
#include signal.h
+#include stdbool.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -86,6 +87,7 @@ main(int argc, char *argv[])
char ibuf[BUFSIZ];
fd_set rfd;
int flushtime = 30;
+ bool readstdin;
aflg = kflg = 0;
while ((ch = getopt(argc, argv, aqkt:)) != -1)
@@ -155,19 +157,20 @@ main(int argc, char *argv[])
doshell(argv);
close(slave);
- if (flushtime 0)
- tvp = tv;
- else
- tvp = NULL;
-
- start = time(0);
- FD_ZERO(rfd);
+ start = tvec = time(0);
+ readstdin = true;
for (;;) {
+ FD_ZERO(rfd);
FD_SET(master, rfd);
- FD_SET(STDIN_FILENO, rfd);
- if (flushtime 0) {
- tv.tv_sec = flushtime;
+ if (readstdin)
+ FD_SET(STDIN_FILENO, rfd);
+ if (!readstdin || flushtime 0) {
+ tv.tv_sec = !readstdin ? 1 : flushtime - (tvec - start);
tv.tv_usec = 0;
+ tvp = tv;
+ readstdin = true;
+ } else {
+ tvp = NULL;
}
n = select(master + 1, rfd, 0, 0, tvp);
if (n 0 errno != EINTR)
@@ -176,8 +179,10 @@ main(int argc, char *argv[])
cc = read(STDIN_FILENO, ibuf, BUFSIZ);
if (cc 0)
break;
- if (cc == 0)
+ if (cc == 0) {
(void)write(master, ibuf, 0);
+readstdin = false;
+ }
if (cc 0) {
(void)write(master, ibuf, cc);
if (kflg tcgetattr(master, stt) = 0
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/bin/script eating 100% cpu with portupgrade and xargs
On Sun, Sep 18, 2011 at 11:57:57PM +0300, Mikolaj Golub wrote: On Sun, 18 Sep 2011 20:24:23 +0300 Kostik Belousov wrote: KB On Sun, Sep 18, 2011 at 02:54:34PM +0300, Mikolaj Golub wrote: On Sun, 18 Sep 2011 13:25:26 +0200 Ronald Klop wrote: RK It is a while since I programmed C, but why will writing 0 bytes give RK the reader an end-of-file? Shouldn't the fd be closed to indicate RK end-of-file? AFAIR, this trick with writing 0 to emulate EOF because we can't close the fd -- we still want to read from it. Poor shutdown(2) for non-socket :-). Colin might tell more... KB Please note that interpreting the receiving of 0 bytes on the terminal KB as EOF is only a convention. If done absolutely properly, script shall KB not interpret zero-byte read as EOF. Might be, the reasonable thing to KB do would be to only look at the stdin once in a second after receiving KB zero-bytes, and switching it back to normal mode if something is read. Ok. I see. Below is the patch that does something like this. Looks fine for me, but I did not tested it. I would also suggest to document this behaviour, which can cause a 1-second pause in processing of the user input, somewhere in script(1) manpage, BUGS ? pgp8OqRUNOhFz.pgp Description: PGP signature
