Comment 24 for bug 431975

Revision history for this message
Sampo (sampo) wrote :

This bug continues to exist.

What: Zombie process consuming 100% cpu, parent pid 1 (init). Unkillable and never goes away (waited 30h).

How to trigger: Use transmission (or any other software) to create over 4GB file (5GB torrent in my case) on
encrypted home directory.

It is NOT filesystem or disk performance problem (filesystem continues to perform for all other purposes and
I waited over 30h for it to possibly sort itself out). It really is something unduely stuck in kernel.

It is probably a bug in many places:

1. Bug in init for not reaping up the zombie
2. Bug in kernel for zombie process consuming resources other than process table slot.
3. Bug in ecryptfs kernel module (or possibly ext4 or their mutual interaction) for getting in the trouble in the first place

Distribution: LinuxMint 12 "lisa" based on Ubuntu 11.10 "Oneric" based on Debian?
uname -a
Linux saz 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux
mount |grep ecrypt
/home/sk/.Private on /home/sk type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=42979cfc6e80278a,ecryptfs_fnek_sig=6261c2e7178a57d3)

It is clear that the bug manifests with officially supported distribution release so the robot
was wrong in closing the bug. Please see https://bugs.launchpad.net/launchpad/+bug/913740
for my attempt to expand the bug to new distribution.

I agree that it is reckless to advertise in install process the ability to encrypt home directories
while this bug persists. Only known workaround is not to encrypt home directory. Bugs like
this help to educate users that encryption is a bad thing - exactly opposite of what was
probably intended by including encrypt home directories feature in the first place.

Cheers,
--Sampo