Re: Bug#468075: this bug/#468075 - sudo: system freeze

[Justin Pryzby <justinpryzby@users.sourceforge.net>]

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 <dburrows@debian.org> 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