Bug#190110: libc6: Sub-processes flaking out.
At Sun, 27 Apr 2003 15:15:08 -0500,
Mark A. Hershberger wrote:
> GOTO Masanori <gotom@debian.or.jp> writes:
>
> >> Note that mounting the old disk in the rebuilt system and using it
> >> for a chrooted environment fails to reproduce the problem. So, I
> >> thought, "perhaps a corrupted kernel" and used dpkg --root=/mnt to
> >> install a new kernel on the old partition. Yet, the problem is
> >> still there if I boot from the old partition after doing this.
> >
> > Does not 2.4.20-686 help you?
>
> I use XFS and so have to custom-compile a kernel. But I think I've
> pretty much ruled out the kernel as the issue here as well (see
> below).
>
> > Hm, so do you have problems only for debuild?
>
> No. For example, I can't start apache-ssl at all. Courier IMAPd is
> giving me terrible problems[1]. And the problem does seem to be time
> related -- the longer the kernel is running the worse the problem
> seems to get.
Hmm, this is really bad state. Can we say it's XFS related problem?
> I mentioned I have two systems that showed the same problem. I
> cleared up some disk space on my other system and did an installation
> there using testing as the source. It works (as I expected).
>
> Now, the interesting thing:
>
> Here is how I'm pretty sure that the problem is not the kernel.
> Running the old system while I configured the chrooted environment[2]
> under /mnt, I found that the chrooted system had no problems -- I was
> able to run 'apt-get dist-upgrade' w/o tar freaking out. Since the
> only difference was the chroot, I would assume that the problem wasn't
> the kernel.
>
> And I did md5sum /lib/libc.so.6, /lib/ld-linux.so.2, etc on the root
> and chroot, but failed to find any differences.
>
> As I said, doing a clean install to testing seemed to do the trick.
>
> Still, this seems like an upgrade problem rather than a glibc problem,
> per se. I'm not how to investigate this further unless someone wants
> me to send them my hard drive.
Umm. If your kernel has no problem, then the on-disk filesystem is
corrupted, and XFS does not handle them well? It seems not glibc
problem. If you put the image on ext3 not XFS, then is this problem
still occured?
> Footnotes:
>
> [1] "Failed to create cache file: maildirwatch Error:
> Input/output error" for most any IMAP command.
>
> [2] It is production, so even though it is buggy I've at least got it
> stumbling along.
Regards,
-- gotom
Reply to: