Thanks for the analysis. Why does it only affect aptitude sometimes (after an upgrade is aborted)? Is that due to some cache? Why isn't apt/itude using mmap (?)?
Out of curiousity, what kernel and hardware are you using? On Fri, Mar 21, 2008 at 08:49:13AM -0700, Daniel Burrows wrote: > On Fri, Mar 21, 2008 at 07:14:15AM -0700, Daniel Burrows <[EMAIL PROTECTED]> > was heard to say: > > Interestingly, if I run these on a text console, other text consoles > > and the programs running in them are unaffected. Only X suffers a > > complete freeze. > > Here's an odd thing. > > If I ssh to localhost, then run the test program I wrote, I get no > freeze. If I run "su" and then run the test program, I get no freeze. > If I run "sudo sh" and then run the test program, I get no freeze. But > "sudo su -c ./test" does freeze. sudo ./test also freezes. (sudo su never made sense to me). > I'm not sure what to make of that. Also, while testing, I tried to minimize the time interval of the freeze, by running: while sleep 4; do sudo killall test2; done That worked (terminated the program after a short interval, but long enough for me to know that it froze). However when I tried (to avoid spamming my syslog with sudo events) this: sudo sh -c 'while sleep 4; do killall test2; done' it didn't work (the root shell loop apparently was frozen). Lacking a better explanation, it seems like processes that were UID 0 at some point in time get stuck, but processes that become UID 0 don't. Apparently, all that's necessary is to loop around lseek with a nonzero "offset". Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]