Defunct Process on Solaris!!!!
Mohammad Khan
We have a paging application which uses /usr/bin/cu utility to connect to
modems and send out pages. Some times on Solaris system the application
will die while sending out a page, which will cause cu process to gin in
defunct state.
This is how the defunct process looks like
uucp 2657 1 0 0:01 <defunct>
Now we can't kill this process. The only way to make the modem active again
is to reboot the system. Now on AIX, we can kill the process.
Does anybody know how to solve this issue?
Thanks.
Robert Sipe
is a process that has sent out a signal that is is done and is ready to die.
However, init has lost track of the process and the defunct process never
receives the signal to die.
"Mohammad Khan" <mk...@crosscom.com> wrote in message
news:3aca5122$0$52...@wodc7nh1.news.uu.net...
Stefaan A Eeckels
A defunct process is a process that has exited, and has a parent,
but has not yet been waited for by that parent.
It seems that the paging application has been badly coded, and
does not wait on the process when it dies. The solution is to
fix the application, as this behaviour is symptomatic for a
sloppily coded program (or a program written by someone who
doesn't grok UNIX).
--
Stefaan
--
How's it supposed to get the respect of management if you've got just
one guy working on the project? It's much more impressive to have a
battery of programmers slaving away. -- Jeffrey Hobbs (comp.lang.tcl)
Don McDonald
> Robert Sipe <rs...@aptlink.com> wrote:
>
> > I can safely say that on an HPUX system you must reboot. A defunt process
> > is a process that has sent out a signal that is is done and is ready to die.
> > However, init has lost track of the process and the defunct process never
> > receives the signal to die.
>
>
> In Unix a defunct process (zombie) is a process that has died but
> its parent has not yet retrieved its exit status (by using one of
> the wait*() functions). The only thing remaining from the defunct
> process is its entry in the process table with associated data.
> All exiting processes passes through the defunct state, but for
> most of them their parent will wait on them and they will go away
> immediately. An application that doesn't wait for its children is
> badly implemented and will create defunct processes. To get rid
> of defunct processes all that has to be done is to kill their
> parent. When this happens they will be adopted by the init process.
> The init process always waits for children.
Then you have a zombie with "init" as its parent. Reboot the
machine and be done with it.
Yours in Christ,
Don
--
*************************************************************************
* Rev. Don McDonald * You a bounty hunter? *
* Baltimore, MD * Man's gotta earn a livin' *
* * Dyin' ain't much of a livin', boy *
* * -- Outlaw Josey Wales *
*************************************************************************
http://members.home.net/oldno7
Jefferson Ogata
[snip]
> To get rid
> of defunct processes all that has to be done is to kill their
> parent. When this happens they will be adopted by the init process.
> The init process always waits for children.
Goran's quite correct. Don't let anyone tell you otherwise. Once a process's
parent exits, init inherits the process and will immediately reap the zombie
entry from the process descriptor table. No reboot is necessary.
Check the options for your ps command to see how you can get a listing that
includes each process's parent's pid.
--
Jefferson Ogata : Internetworker, Antibozo
<og...@antibozo-u-spam-u-die.net> http://www.antibozo.net/ogata/
whois: jo...@whois.networksolutions.com
Don McDonald
> Goran Larsson wrote:
> [snip]
> > To get rid
> > of defunct processes all that has to be done is to kill their
> > parent. When this happens they will be adopted by the init process.
> > The init process always waits for children.
> Goran's quite correct. Don't let anyone tell you otherwise. Once a process's
> parent exits, init inherits the process and will immediately reap the zombie
> entry from the process descriptor table. No reboot is necessary.
Actually it won't, Jeff. Unless you kill "init" (which amounts to
a reboot anyway), you'll have a zombie forever.
Happy to have cleared things up for you,
Don
--
*************************************************************************
* Don McDonald * You a bounty hunter? *
Don McDonald
>
> On Thu, 05 Apr 2001 04:25:32 GMT, in article <3ACBF3EE...@home.com>, Don
> Rev. Don Kool <old...@home.com> wrote:
> >Jeff Ogata wrote:
> >> Gary Larsson wrote:
> >> [snip]
> >
> >> > To get rid
> >> > of defunct processes all that has to be done is to kill their
> >> > parent. When this happens they will be adopted by the init process.
> >> > The init process always waits for children.
> >> Goran's quite correct. Don't let anyone tell you otherwise. Once a process's
> >> parent exits, init inherits the process and will immediately reap the zombie
> >> entry from the process descriptor table. No reboot is necessary.
> > Actually it won't, Jeff.
> Actually, it WILL, Don. Shows what little YOU know.
Actually, it won't, Gary.
Nate Eldredge
> Jefferson Ogata wrote:
> > Goran Larsson wrote:
>
> > [snip]
>
> > > To get rid
> > > of defunct processes all that has to be done is to kill their
> > > parent. When this happens they will be adopted by the init process.
> > > The init process always waits for children.
>
> > Goran's quite correct. Don't let anyone tell you otherwise. Once a process's
> > parent exits, init inherits the process and will immediately reap the zombie
> > entry from the process descriptor table. No reboot is necessary.
>
> Actually it won't, Jeff. Unless you kill "init" (which amounts to
> a reboot anyway), you'll have a zombie forever.
Nonsense.
nate@turing:~$ cat foo.c
#include <unistd.h>
#include <stdio.h>
int main(void)
{
pid_t p = fork();
if (p == 0) {
printf("Child has PID %d, watch it\n", getpid());
exit(0);
} else if (p > 0) {
printf("Parent exiting without waiting\n");
exit(0);
} else {
perror("fork");
exit(1);
}
return 0; /* not reached */
}
nate@turing:~$ cc foo.c
nate@turing:~$ ./a.out
Parent exiting without waiting
Child has PID 90, watch it
nate@turing:~$ ps -p 90
PID TTY TIME CMD
nate@turing:~$
Note the utter lack of a PID 90.
Incidentally, I notice you no longer use the title "Rev." Any
particular reason for this? I personally am rather fond of my
religious titles, all of which, I might add, are entirely legitimate.
Yours in Universal Life,
--
His Eminence The Reverend Nate, Cardinal Eldredge (ULC)
neld...@hmc.edu
Jefferson Ogata
[a nice demonstration of a zombie being cleaned up automatically]
Here's a slightly different example:
# uname -srm
SunOS 5.8 sun4m
# cat x.c
#include <stdio.h>
#include <sys/types.h>
int main (void)
{
pid_t pid;
if ((pid = fork ()) == 0)
{
close (0);
close (1);
close (2);
_exit (0);
}
printf ("parent is %d\n", getpid ());
printf ("child is %d\n", pid);
while (1)
{
sleep (1);
}
return 0;
}
# gcc -o x x.c
# truss -t wait -v wait -o init.truss -p 1 &
3384
# ./x &
3385
# parent is 3385
child is 3386
ps -f -p 3385,3386
UID PID PPID C STIME TTY TIME CMD
root 3385 3350 1 12:35:17 pts/3 0:00 ./x
root 3386 3385 0 0:00 <defunct>
# kill -9 3385
#
3385 Killed
# ps -f -p 3385,3386
UID PID PPID C STIME TTY TIME CMD
# cat init.truss
Received signal #18, SIGCLD, in pause() [caught]
siginfo: SIGCLD CLD_EXITED pid=3386 status=0x0000
waitid(P_ALL, 0, 0xEFFFFB80, WEXITED|WNOHANG|WNOWAIT) = 0
siginfo: SIGCLD CLD_EXITED pid=3386 status=0x0000
wait() = 3386 [0x0000]
waitid(P_ALL, 0, 0xEFFFFB80, WEXITED|WNOHANG|WNOWAIT) = 0
siginfo: SIG#0
Note that we actually observe init reaping the zombie.
I've seen one reference stating that on some operating systems, if a process
exits before its parent and its parent then exits without waiting for it, it
will remain a zombie, presumably because init won't reap a process that is
already a zombie. I don't know if that's true on HP, but as the above clearly
demonstrates, it's certainly not the case on Solaris.
Dave Hinz
: That's a problem for don. He doesn't know HOW to fix a problem in UNIX.
: Rebooting is his only option.
Well, of course. He's a windows guy, after all, and is in over his
head in the modern world of Unix & Linux. That's why he's afraid of
anyone who knows more than he (that would be, pretty much anyone).
Jimi Thompson
Once you kill the parent, see if the children are still running. Then, if
you must, you can kill the children and not have to restart. There are a
great many Perl scripts for this very thing. You can set one to run as a
cron.
Stefaan A Eeckels <Stefaan...@ecc.lu> wrote in message
news:09nea9...@justus.ecc.lu...
Don McDonald
> Don McDonald <old...@home.com> wrote:
> > Goran Larsson wrote:
> > > parent. When this happens they will be adopted by the init process.
> > > The init process always waits for children.
> > Then you have a zombie with "init" as its parent. Reboot the
> > machine and be done with it.
> If a defunct process has init as its parent for so long that you can
> observe it (and ponder about what to do about it) then
you reboot and stop fretting about losing your "uptime" record.
Get a life, get going and get your users back to work, morons.
Happy to have cleared things up for you,
Don
--
*************************************************************************
* Don McDonald * You a bounty hunter? *
Don McDonald
> >> Rev. Don Kool <old...@home.com> wrote:
> >> >Jeff Ogata wrote:
> >> >> Gary Larsson wrote:
> >> >> [snip]
> >> >> > To get rid
> >> >> > of defunct processes all that has to be done is to kill their
> >> >> > parent. When this happens they will be adopted by the init process.
> >> >> > The init process always waits for children.
> >> >> Goran's quite correct. Don't let anyone tell you otherwise. Once a process's
> >> >> parent exits, init inherits the process and will immediately reap the zombie
> >> >> entry from the process descriptor table. No reboot is necessary.
> >> > Actually it won't, Jeff.
> >> Actually, it WILL, Don. Shows what little YOU know.
> > Actually, it won't, Gary.
> If you used a REAL UNIX, baby raper, it would. Try Solaris.
Perhaps one day proven child molester Gary Burnore will learn
enough about computers to figure out how to read headers. Eat my
headers, "Forté Agent 1.7/32.534" boy. Learn to use your newsreader
and you'll see that the posting you're responding to contains the
header "X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)".
Since you have demonstrated on occassions too numerous to mention
that you know nothing of UNIX systems, I'll point out the fact to
you that "SunOS 5.8" is the latest version of "Solaris [sic]". I'm
posting from a UNIX system and you're posting from a PC. Proof once
again that those of use who know UNIX systems can use UNIX systems
and those of you who confuse LINUX/FreeBSD/etc. with a UNIX system,
couldn't configure a UNIX system out of a paper bag. Stick with
your PC, my child, it suits you. ROTFLOLASTD!!!!!!
Don McDonald
> Don McDonald <old...@home.com> writes:
> > Jeff Ogata wrote:
> > > Goran Larsson wrote:
> > > [snip]
> > > > To get rid
> > > > of defunct processes all that has to be done is to kill their
> > > > parent. When this happens they will be adopted by the init process.
> > > > The init process always waits for children.
> > > Goran's quite correct. Don't let anyone tell you otherwise. Once a process's
> > > parent exits, init inherits the process and will immediately reap the zombie
> > > entry from the process descriptor table. No reboot is necessary.
> > Actually it won't, Jeff. Unless you kill "init" (which amounts to
> > a reboot anyway), you'll have a zombie forever.
> Nonsense.
Actually; the god's honest truth, my child.
[...Nate's nonsense snipped...]
> Incidentally, I notice you no longer use the title "Rev." Any
> particular reason for this?
Just bought a couple new computers this week and haven't taken the
time to get them both properly configured as yet. Unfortunely, I'm
sure the change is wreaking havoc with some of our more cowardly
posters "killfiles". Hopefully they won't soil their desk chairs
before I reconfigure my systems back to DonKool standard. In any
event, not my problem.
Thanks for your interest.
Yours in Christ,
Don McDonald
> Don McDonald <old...@home.com> wrote:
> >Goran Larsson wrote:
> >> Don McDonald <old...@home.com> wrote:
> >> > Goran Larsson wrote:
> >> > > parent. When this happens they will be adopted by the init process.
> >> > > The init process always waits for children.
> >> > Then you have a zombie with "init" as its parent. Reboot the
> >> > machine and be done with it.
> >> If a defunct process has init as its parent for so long that you can
> >> observe it (and ponder about what to do about it) then
> > you reboot
> No,
Actually "YES", my PC using friend. Leave UNIX to us UNIX
professionals and keep posting from your little PC, Shorty.
Andrew Gierth
>> To get rid of defunct processes all that has to be done is to kill
>> their parent. When this happens they will be adopted by the init
>> process. The init process always waits for children.
Jefferson> Goran's quite correct. Don't let anyone tell you
Jefferson> otherwise.
'fraid I have to disagree with both of you.
Jefferson> Once a process's parent exits, init inherits the process
Jefferson> and will immediately reap the zombie entry from the
Jefferson> process descriptor table. No reboot is necessary.
On some systems, having an incorrect 'wait' entry in inittab (for a
process that never exits) can prevent init from getting on with the
job of reaping orphaned zombies, but this doesn't sound like the
original poster's problem.
More likely, his "defunct" process is _not in fact a zombie_, but a
process blocked inside _exit(). Annoyingly, many implementations of
the ps command fail to clearly distinguish these two quite different
states. Given that a serial port is involved, the problem is almost
certainly that the program has data buffered for output to the serial
port, that the serial modes and current state of the handshake lines
don't allow that data to be output, and that the last close on the
port (triggered by the process exit) is blocked waiting for the output
to drain.
--
Andrew.
Stefaan A Eeckels
Andrew Gierth <and...@erlenstar.demon.co.uk> writes:
>
> More likely, his "defunct" process is _not in fact a zombie_, but a
> process blocked inside _exit(). Annoyingly, many implementations of
> the ps command fail to clearly distinguish these two quite different
> states. Given that a serial port is involved, the problem is almost
> certainly that the program has data buffered for output to the serial
> port, that the serial modes and current state of the handshake lines
> don't allow that data to be output, and that the last close on the
> port (triggered by the process exit) is blocked waiting for the output
> to drain.
That's the best explanation of his problems, and the only one
that explains why he has to reboot the system. It also explains
why it works on HPs, and fails on Suns.
I suppose that the original poster has access to the source code;
if he cares to give a reference, it shouldn't be too difficult to
find the problem.
(I spent a whole year back in the 1980ies writing UNIX serial
port code; some of the (painful) experiences ought to come
rushing back all too easily :-)
Stefaan A Eeckels
"Jimi Thompson" <JI...@prodigy.net> writes:
Please don't quote Jeopardy-style.
> You need to do ps -aef (I think, but read man ps). Then kill the parent.
> Once you kill the parent, see if the children are still running. Then, if
> you must, you can kill the children and not have to restart. There are a
> great many Perl scripts for this very thing. You can set one to run as a
> cron.
That's a purely symptomatic treatment, which is about the
only thing you can do if the code is not available.
I'd get the program fixed if possible. This shouldn't
be too much of a problem:
1. It's an in-house development, so they have the code
and can buy the services of a decent UNIX developer.
2. It's a commercial closed-source product, so they can
tell the company to fix it.
3. It's open-source, so they can either fix it themselves,
or send in a bug report.
None of these actions is overly complex (and quite possibly
less complex than installing the band-aid you've described).
Don McDonald
You left out the part where the only way to kill that "zombie" is
to reboot. More proof that Gary burnore doesn't know his ass from a
hole in the ground (or a minor from an adult or a UNIX system from a
LINUX PC).
Don McDonald
> Your inability to read english got you again, Don. He said, and was most likely
> correct, that it wasn't a zombie process. If you were more than just a NOC
> Monkey, you'd understand the difference.
Gary has as much problem understanding the use of quotation marks
as he does with understanding that under 18 means off limits.
Happy to have cleared things up for you,
Andrew Gierth
>> More likely, his "defunct" process is _not in fact a zombie_, but
>> a process blocked inside _exit(). Annoyingly, many implementations
>> of the ps command fail to clearly distinguish these two quite
>> different states. Given that a serial port is involved, the
>> problem is almost certainly that the program has data buffered for
>> output to the serial port, that the serial modes and current state
>> of the handshake lines don't allow that data to be output, and
>> that the last close on the port (triggered by the process exit) is
>> blocked waiting for the output to drain.
Don> You left out the part where the only way to kill that "zombie"
Don> is to reboot.
because it's not necessarily the case. Whether the port can be
unblocked without requiring a reboot will depend on the system, and
possibly also on the external device. e.g. convincing the external
device to assert the relevent handshaking lines may be sufficient, or
it may (or may not) be possible to open the port from another program
and either flush the output buffer or disable the flow control.
I don't know offhand whether Solaris is amenable to any of these
solutions, because my serial comms experience is with other systems.
--
Andrew.
Don McDonald
On SOLARIS the solution is to reboot.
Don McDonald
>
> On Wed, 11 Apr 2001 23:35:18 GMT, in article <3AD4EA68...@home.com>, Don
> McDonald <old...@home.com> wrote:
>
> > On SOLARIS the solution is to reboot.
>
> does things the _RIGHT_ WAY.
Sadly my convicted child molstester friend, that is the solution on
all SOLARIS systems. :-(
Happy to have cleared things up for you,
wav3D
WHO ARE YOU CALLING BABY RAPER YOU FUCKING MAGGOT? YOU RTRIED TO RAPE
YOUR OWN DAUGHTER. YOUR WORDS FUCK FACE, NOT MINE.
ARE YOU REGISTERED IN N.C.? NO. SHOULD YOU BE? YES. IF YOU MOVE BACK TO
CALIFORNIA, DO YOU HAVE TO? YES! REMEMBER THAT YOU FUCKING CHILD MOLESTING,
PG&E DEFRAUDING, ASS SLURPING, LYING, DENEGRATED FUCK FACE!
In article <9b5u87$kmn$1...@intimidator.databasix.com>, Gary says...
>
>On Fri, 13 Apr 2001 03:36:00 GMT, in article <3AD67451...@home.com>, Don
>McDonald <old...@home.com> wrote:
>
>>"Gary L. Burnore" wrote:
>>>
>>>On Wed, 11 Apr 2001 23:35:18 GMT, in article <3AD4EA68...@home.com>, Don
>>> McDonald <old...@home.com> wrote:
>>>
>>> > On SOLARIS the solution is to reboot.
>>>
>>>That should read "On DON'S SOLARIS, the solution is to reboot." Everyone else
>>> does things the _RIGHT_ WAY.
>>
>> Sadly my convicted child molstester friend,
>
>You're stuttering again, Baby Raper.
>--
> for i in databasix.com primenet.com ; do ; gburnore@$i ; done
>---------------------------------------------------------------------------
> How you look depends on where you go.
>---------------------------------------------------------------------------
>Gary L. Burnore | нлГКнГоГКнГГнлКнГоГКнГнГоГКнГннлГ
> | нлГКнГоГКнГГнлКнГоГКнГнГоГКнГннлГ
>Black Helicopter Repair Services, Ltd.| нлГКнГоГКнГГнлКнГоГКнГнГоГКнГннлГ
> | нлГ 3 4 1 4 2 нГоГ 6 9 0 6 9 нлГ
>spamgard(tm): zamboni | Official Proof of Purchase
>===========================================================================
wav3D
REBOOT BECAUSE OF ZOMBIES? YOU FUCKING PATHETIC P-O-S-E-R[POSER!]
YOU ARE A FUCKING POSER. GO AWAY. WE DONT ENED YOUR HELP. GO FETCH A
STICK OR SOMETHING AND ENTERTAIN US.
In article <9b4ua0$i0e$1...@intimidator.databasix.com>, Gary says...
>
>On Wed, 11 Apr 2001 23:35:18 GMT, in article <3AD4EA68...@home.com>, Don
>McDonald <old...@home.com> wrote:
>
>
>> On SOLARIS the solution is to reboot.
>
>That should read "On DON'S SOLARIS, the solution is to reboot." Everyone else
>does things the _RIGHT_ WAY.
>