[DRBD-user] Zombie, Zombie?

[Lars Ellenberg]

please reply to the list.

/ 2004-04-26 12:17:52 +0200
\ Andreas Semt:
> >>I use DRBD 0.6.12 (with heartbeat 1.21). Sometimes I get some real high 
> >>load on my machine (load average around 6) and a zombie process like 
> >>drbd_syncer_2 or drbd_syncer_3. I believe the zombie process causes the 
> >>high load. Also i lost a drbd connection without reason (one connection 
> >>of four).
> >>Additional information: the zombie processes disappear after some time 
> >>and the load is normal again. Zombies exist only on the drbd "PRIMARY" 
> >>machine (all drbd devices in primary mode).
> >>
> >>My questions:
> >>
> >>1. Could it be a zombie process who killed the drbd connection?
> >
> >
> >No. It is only killed *after* the connection was lost.
> >Unfortunately it is not always reaped immediately.
> >Zombie processes cannot cause load, because they are dead.
> >They only waste some memory and process slots.
> >
> 
> Okay, the high load is explained in the FAQ (sorry).
> Can you say what exactly drbd_syncer and drbd_asender doing?


syncer reads in the blocks that need to be synced from local disk,
and sends over to the peer.

asender sends ACKknowledgement packets for written data, and for
drbd-pings, and itself sends drbd-ping-requests if neccessary.

> >>2. Why these Zombies live on my machine?
> >
> >If you care, you can use 0.6.12 CVS HEAD, which differs basically only
> >by a "reparent to init" call right after our thread startup, as it
> >should have been from the very begining. now, the "zombies" are reaped
> >by init almost immediately after their death.
> >
> 
> Is that a common behavior of drbd (to create "zombies") or a bug or 
> something else?

Not a bug, as long as they get reaped eventually.
Unusual bahaviour, if it takes "long" to reap them.
A bug if they stay around for ever.

Unusual in general, because typically kernel threads should be
reparented to init anyways.
"historically" drbd wanted to reap its child threads itself.

	Lars Ellenberg