Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!hplsla!hpubvwa!grlab!scott
From: scott@grlab.UUCP (Scott Blachowicz)
Newsgroups: comp.sys.hp
Subject: Re: Lots of zombies on HP-UX (2.1, 3.1), all children of remshd
Message-ID: <240043@grlab.UUCP>
Date: 14 Jul 89 18:27:34 GMT
References: <4023@hemuli.atk.vtt.fi>
Organization: Graphicus
Lines: 26

/ grlab:comp.sys.hp / jack@hpindda.HP.COM (Jack Repenning) /  1:19 pm  Jul 10, 1989 /
> I've seen persistent zombie children of remshd when people remsh
> processes that they put into background, e.g.:
> 
>         remsh m840 hpterm -display $DISPLAY \& &
> 
> If this is happening, you should find active processes belonging to
> the same users (the hpterm, in the example).  These will be the
> program started by the zombie (which was a shell).

This isn't exactly the same problem you're seeing, but...
I got tired of seeing remshd hanging out in memory waiting on stuff, so 
I wrote a remsh replacement (I call qremsh) that just does the remote
schedule without wait & dies. It closes off stdin/out/err before doing
the remote schedule (uses inetd). It was both an exercise in using the
network programming and conserving memory. I'm not sure if I'm missing
something, but it seems to work fine for what I want to do
(hpterm,xload,etc) since none of them care about stdin/out/err that they
inherit.

Let me know if you want it & I'll try to package it up.

Scott Blachowicz
USPS:  Graphicus                UUCP:    ...!hpubvwa!grlab!scott
       150 Lake Str S, #206     VoicePh: 206/828-4691
       Kirkland, WA 98033       FAX:     206/828-4236