Unix administration - init + orphaned processes

Author

init + orphaned processes

Matty

2004-03-29, 12:35 am

Howdy,

We have a vendor application that is invoked from
users shell after they login. The application is
invoked similar to:

exec /usr/local/app/blah

This causes the program to execute in place of
the shell (not sure why the vendor coded it this
way). For some reason, when users disconnect,
the processes (blah in this case) goes off into
lala land. The PPID is 1, which should allow init
to clean it up. Does anyone know when init will
terminate processes it inherits and reclaim
the resources? If anyone has a good link or explanation,
that would be awesome. I am parsing through Advanced
Programming in the UNIX Environment in an attempt to
find an answer.

Thanks for any insight,
- Ryan

Michael Vilain

2004-03-29, 1:38 am

In article <pan.2004.03.29.05.34.35.425656@bellsouth.net>,
Matty <mattyml@bellsouth.net> wrote:

> Howdy,
>
> We have a vendor application that is invoked from
> users shell after they login. The application is
> invoked similar to:
>
> exec /usr/local/app/blah
>
> This causes the program to execute in place of
> the shell (not sure why the vendor coded it this
> way). For some reason, when users disconnect,
> the processes (blah in this case) goes off into
> lala land. The PPID is 1, which should allow init
> to clean it up. Does anyone know when init will
> terminate processes it inherits and reclaim
> the resources? If anyone has a good link or explanation,
> that would be awesome. I am parsing through Advanced
> programming in the UNIX Environment in an attempt to
> find an answer.
>
> Thanks for any insight,
> - Ryan

This is called a zombie process and is the result of the parent process
exiting before terminating the child (e.g. your the local application).
Usually this is due to a poorly designed application or bug. Since your
application is started this way, it needs to be 'cleaned up' when
someone logs out by killing it with a kill command. You can fix this
with a .logout or the equivalent in the shell you're using.

Or you can file a bug report with the vendor and tell them to fix their
piece of crap application so that it runs properly.

By the way, what is the application, so we all know who wrote it.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Paul Pluzhnikov

2004-03-29, 2:39 am

Matty <mattyml@bellsouth.net> writes:

> Does anyone know when init will
> terminate processes it inherits and reclaim
> the resources?

Init never does *that*.

What it does do is wait(2) for *already* terminated processes
(aka zombie processes).

If you actually do have zombie processes, and they are not cleaned
up by init, then your init process is likely stuck. One reason this
could happen is given here:

1.153 Why does init not reap its zombie child processes?
http://www.faqs.org/faqs/aix-faq/part1/section-61.html

If you are not on AIX, pray tell what OS you are on, and what the
'ps -ef' output for "stuck" processes looks like.

> I am parsing through Advanced
> programming in the UNIX Environment in an attempt to
> find an answer.

Why not ask the application vendor how the app is supposed to
be terminated?

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Villy Kruse

2004-03-29, 3:35 am

On Sun, 28 Mar 2004 21:51:44 -0800,
"Michael Vilain <vilain@spamcop.net>" <> wrote:

>
> This is called a zombie process and is the result of the parent process
> exiting before terminating the child (e.g. your the local application).

(sigh) No, it is an orphan. An orphan is a child with no parent, also
when when you talk about processes on a unix system.

> Usually this is due to a poorly designed application or bug. Since your
> application is started this way, it needs to be 'cleaned up' when
> someone logs out by killing it with a kill command. You can fix this
> with a .logout or the equivalent in the shell you're using.
>

Orphan processes is quite normal; most daemons on unix are actualy
orphans. Normaly, when you log out a SIGHUP is sent by the kernel to
all forground processes which should cause them to terminate. The
forground shell should catch the SIGHUP signal and terminate all its
background jobs.

A zombie is something or someone that is supposed to be dead but isn't
quite dead yet. A zombie with no parents becomes an orphaned zombie and
the init process will do whatever is required to get rid of the zombie.
If the zombie does have a parent then it is the responsibility of the
parent process to do this by calling wait(). You will often see that
when you have a zombie process it will disappear as soon as the parent
process terminates.

Villy

Frank Cusack

2004-03-29, 4:41 am

On Mon, 29 Mar 2004 00:34:35 -0500 Matty <mattyml@bellsouth.net> wrote:
> Howdy,
>
> We have a vendor application that is invoked from
> users shell after they login. The application is
> invoked similar to:
>
> exec /usr/local/app/blah
>
> This causes the program to execute in place of
> the shell (not sure why the vendor coded it this
> way). For some reason, when users disconnect,
> the processes (blah in this case) goes off into
> lala land. The PPID is 1, which should allow init
> to clean it up. Does anyone know when init will
> terminate processes it inherits and reclaim
> the resources?

When the process exits. PPID of 1 only means that init will clean it
up when it does exit. You'll notice there's lots of running processes
with PPID 1.

Sounds like a poorly written application.

/fc

Frank Cusack

2004-03-29, 4:41 am

On Sun, 28 Mar 2004 21:51:44 -0800 "Michael Vilain <vilain@spamcop.net>" wrote:
> In article <pan.2004.03.29.05.34.35.425656@bellsouth.net>,
> Matty <mattyml@bellsouth.net> wrote:
....
....[color=darkred]
>
> This is called a zombie process and is the result of the parent process
> exiting before terminating the child (e.g. your the local application).

That is not a zombie. A zombie is a terminated process that the still
alive parent hasn't yet called wait(2) on.

/fc

Doug Freyburger

2004-03-29, 9:49 am

Matty wrote:
>
> This causes the program to execute in place of
> the shell (not sure why the vendor coded it this
> way).

Poor coding mostly.

> For some reason, when users disconnect,
> the processes (blah in this case) goes off into
> lala land. The PPID is 1, which should allow init
> to clean it up.

Having a PPID of 1 does NOT mean it has become a zombie.
It means it has gone "nohup" so when users disconnect
it will not autmoatically be terminated. See the man
page for nohup on the uses of this.

1) What you have is a program that takes specific effort
to become immune to hangups, and your users hang up on it.
This is at least partially a user training issue. Teach
them to "don't do that then". Seriously. The program
must have some way for them to exit it before they
logout or drop the modem connection or whatever they are
doing. Exitting programs on the screen before logging
out is something that every SysAdmin *must* do to set an
example for our users, and it is something that users
must do to prevent this sort of problem.

> Does anyone know when init will
> terminate processes it inherits and reclaim
> the resources?

Init never terminates procresses, it just waits for them
after the exit. ps output for these programs will not
show them to be "<defunct>" so they still think they are
waiting on user input.

You will need to kill the old ones by hand, and as your
new training program starts to work you will gradually
have fewer and fewer of them to deal with.

2) Also complain to the vendor that it is going nohup and
ask them how to stop it from nohup'ing. If you switch it
to not nohup, when the users hang up they will terminate
in their own and do your clean-up for you.