Bug#190110: libc6: Sub-processes flaking out.
At Sun, 27 Apr 2003 15:15:08 -0500,
Mark A. Hershberger wrote:
> GOTO Masanori <firstname.lastname@example.org> 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
> > 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. 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
> 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
>  "Failed to create cache file: maildirwatch Error:
> Input/output error" for most any IMAP command.
>  It is production, so even though it is buggy I've at least got it
> stumbling along.