[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 16 Aug 2010 15:45:55 +0200
> I've first seen this problem after having had the following command
> line run for a week, or two, or three:
> Start `screen`. Find PID of pfinet.
> $ while sleep 66; do echo "$(date)" " $(ps --no-header
> --format=hurd -p [PID])"; done | tee ps-pfinet
> Leave it running, detach from `screen`.
> Eventually, the main `bash` process will go bonkers and eat 100 % CPU
> time. Reproduced on four different systems.
> A faster way to reproduce this, again inside `screen`; every three
> seconds, write text in 10 MiB bursts to the terminal:
> $ while sleep 3; do date > tmp/tmp && yes "$(date)" | dd bs=1M
> count=10; done
> This one only needs like ten hours, before `bash` starts its
> busy-loop, from which it can only be terminated with `SIGKILL`. At
> this point, the `term`, `screen`, `fifo` processes also have used 40,
> 52, 25 minutes of CPU time, respectively, but appear to be still
> working fine.
> I did not yet start debugging this.
I think that's the same issue I'm seeing with my port log.
(Investigating this has been on my ToDo for a while...) I'm running a
script that saves the output of ps (and vmstat) every 5 seconds, and it
makes bash go bonkers after about one day. (It's running as a daemon, so
neither screen nor terminals involved.)
The common theme here seems to be a sleep loop... Or repeated I/O. I'll
check whether a NOP loop also causes a hang. And whether it happens with