[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#639453: linux-image-2.6.39-bpo.2-amd64: Dropped Connections and "Failed to create cgroup nnnn: -17" Kernel Message When vsftpd Spawning a New Process



On Sat, 2011-08-27 at 12:38 +0200, Dirk Weinhardt wrote:
> Package: linux-2.6
> Version: 2.6.39-3~bpo60+1
> Severity: normal
> 
> 
> I am experiencing the following issue with a Debian squeeze based
> server and the most recent squeeze-backports kernel:
> 
> I realized that some vstfpd daemons randomly drop connections (sending
> a FIN right after the initial TCP hand shake was completed).
> Furthermore, a "Failed to create cgroup nnnn: -17" message is logged
> by the kernel.
> 
> Furthermore, I am observing a steadily increasing number of
> directories named like pids being created in the root of the cgroup
> virtual filesystem (mounted at /cgroup). For each connection attempt
> to a vsftpd daemon a new directory is created. Those directories seem
> to be never deleted. After a few days of uptime there are about 7,500
> directories while there constantly are only about 150 processes
> running (more or less idling, this server usually has low load).

Do they persist if you restart vsftpd?

> When stracing vsftpd the call that fails seems to be this one (full
> output below):
> 
> clone(child_stack=0, flags=0x28000000|SIGCHLD) = -1 EEXIST (File
> exists)
> 
> Which makes me believe that those "zombie directories" in /cgroup
> might conflict with the new pid . The longer the server is up the more
> likely it becomes that connections are dropped.
> 
> Side note: The affected vsftpd daemons are running on a server that
> also is hosting an LXC-based virtual server. I have experienced a
> steadily increasing soft IRQ load on the server while a cgroup virtual
> filesystem being mounted. I have upgraded to the recent
> squeeze-backports kernel which seems not to suffer from this soft IRQ
> issue.
[...]

That is bug #629373.

Ben.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: