>> For those who can reproduce it an have something like libnss-db
>> enabled, try disabling it.
- disabled it
- running vgdisplay killed the machine (wanted to create a new LV for a
chroot)... it's not accessible at all anymore, I think the kernel is
a 2.6.23-something here, I'll build a rec
Josip Rodin wrote:
> On Sat, Oct 27, 2007 at 12:30:56AM +0200, Bernd Zeimetz wrote:
>>> Josip, do you guys have libnss-db or similar in use on the buildd
>>> machine?
>> They have, that's what Debian's userdir-ldap uses.
>
> No, I have to correct you, this machine isn't part of that setup
> (at le
On Sat, Oct 27, 2007 at 12:30:56AM +0200, Bernd Zeimetz wrote:
> > Josip, do you guys have libnss-db or similar in use on the buildd
> > machine?
>
> They have, that's what Debian's userdir-ldap uses.
No, I have to correct you, this machine isn't part of that setup
(at least not yet).
--
2
On Fri, Oct 26, 2007 at 03:01:24PM -0700, David Miller wrote:
> One thing I notice in the debian bug report is a mention of libnss-db
>
> So I did some testing here and without libnss-db installed, running
> dpkg-query does not use futexes at all.
>
> But once I install libnss-db and enable it (b
> Josip, do you guys have libnss-db or similar in use on the buildd
> machine?
They have, that's what Debian's userdir-ldap uses.
> For those who can reproduce it an have something like libnss-db
> enabled, try disabling it.
Will do in a few minutes.
--
Bernd Zeimetz
<[EMAIL PROTECTED]>
From: Bernd Zeimetz <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 14:30:21 +0200
> at least it runs with 100% CPU, attaching strace to the pid doesn't give
> any results
> strace-ing the whole process doesn't result in more useful output, but
> the hanging processes were killable when they were r
Hi,
just got linked to this thread, so here's a bit input form me :)
>> 1) system type
>
> A Sun Fire 280R, with two CPU boards, each carrying a TI UltraSparc III
> (Cheetah), and 2 GB of RAM. If you need more info, just say.
>
> (Bernd Zeimetz has previously suggested that the problem is link
Hi,
> It seems that instead of getting stuck in the kernel where I
> thought it would, the process gets stuck elsewhere and
> also tends to loop allocating memory until all memory in the
> machine is exhausted and the OOM killer starts to try and
> kill processes left and right.
at least it runs
From: Josip Rodin <[EMAIL PROTECTED]>
Date: Thu, 25 Oct 2007 17:07:36 +0200
> I did this in a chrooted bash:
>
> for i in $(seq 0 100); do (dpkg-query -s python2.5-minimal > /dev/null &);
> done
>
> And now the machine went catatonic. :(
>
> Thankfully the console is still vaguely operational
