Messages in this thread | | | Date | Mon, 7 Jul 2008 00:08:58 +1000 (EST) | From | Tim Connors <> | Subject | Re: tty session leader issue (was Re: 2.6.25.3: su gets stuck for root) |
| |
On Wed, 2 Jul 2008, Joe Peterson wrote:
> I have done some more investigation on this problem, and I am posting > here my results in hope that someone can point me in the right direction > for further investigation... > > Summary: during the initialization of a new bash shell, the terminal > foreground process group often reverts back to that of the parent of the > bash shell (after being set *to* the bash shell pgrp by bash), > prohibiting commands like stty from being run by the init scripts. The > result is that the execution of these commands will hang until killed, > causing the bash prompt to not appear. Adding a delay in the script > (using sleep) increases the chance of this having time to happen. ... > So here is the question: is there a way/reason the kernel would revert > the pgrp of the session leader after bash sets it? Is there some more > instrumenting in the kernel or in bash that might reveal what is going > on? I have heard yet another report of this happening since I added to > the thread, and I can get it to happen easily on two different machines > (a desktop and a laptop).
In fact, in various laptops (Eeeepc, dell inspiron 1520, Dell inspiron 4000), I've got various tty screwups that have been introduced since circa 2.6.19.
The 6 year old inspiron 4000 gets stuck at stty erase ^? . Randomly, but most of the time.
All of my machines exhibit the ctrl-C being slower than ctrl-Z discussed elswhere (I've almost developed a habit of typing ctrl-Z kill %1 <RET>). Although even ctrl-Z recently has been reluctant to always work. I wonder if this is the cause of dpkg recently not responding to ctrl-Z's? (debian bug #486222). dpkg does respond to kill -STOP
ctrl-s doesn't always work anymore. Again, what prompted me to write this email, was I couldn't pause dpkg. It's particularly unreliable at stopping scrolling messages at bootup, and if I press it at the wrong time at bootup (not a specific place - it can be starting up any number of scripts), something deadlocks and won't resume upon a ctrl-q. alt-sysrq-k is enough to kill whatever has deadlocked. I have a feeling, but don't want to test on this system right now, that pressing scroll-lock as opposed to ctrl-q once unlocked such a stuck display.
In summary, something in tty is certainly screwed. Does anyone see a connection between all of these?
-- TimC > cat ~/.signature Electromagnetic pulse received (core dumped)
| |