Hi, > 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 another shell. -antrik-
