Hi Silviu,
Am Freitag 03 M 2006 16:43 schrieb Silviu Marin-Caea:
Btw, did you try kill -SIGSTP ?
I tried killing it with:
-SIGTERM
-SIGKILL
-SIGSTP
-SIGCHLD
None of it work.
ps auex gives this output:
oracle 11109 9.6 0.0 0 0 ? Zl 15:34 10:24 [f90webm]
<defunct>
I could try restarting Forms, but this is not an acceptable long term
solution.
Does anyone have other suggestions?
I am sorry, but just ask "how does a process become a zombie?", and you will
find that killing it is nonsense. A process becomes a zombie, when the
following happens:
A process having child processes (or just thinks it has) receives any kind of
kill signal. If the sense of the child process forbids to re-parent it to
init itself, the parent process (effectively) kills the child and waits for
the child to die, too. But what if the child has already died and the parent
did not realize? Then it will wait forever for the child's death: You have a
zombie, an "undead" process which should NT eat any ressources anymore,
because it is outside of the kernel timeslice (<defunctmeans this).
Normally, the init process cleans up the process table from time to time and
zombies will run out of lifetime. But I am not sure about cleanup behaviour
of kernels < 2.6.
Best regards,

Monday 06 March 2006 10:20, Martin Klier wrote:

You have a zombie, an "undead" process which should NT eat any ressources

The theory is all fine, but I'm looking at 99% CPU Zombie:

27934 oracle 16 0 0 0 0 Z 99.9 0.0 97:31.13 f90webm <defunct>

We have restarted forms and the zombie become child of init. But init cannot
clean it either.

I have looked into /proc/PID_of_zombie

It has a directory named tasks that contains two subdirectories:
27934 PID_of_zombie
32001 (this process does not exist - !!interesting!!)

cat /proc/27934/task/32001/status
Name: f90webm
State: R (running)
SleepAVG: 133%
Tgid: 27934
Pid: 32001
PPid: 1
TracerPid: 0
Uid: 59 59 59 59
Gid: 54 54 54 54
FDSize: 1024
Groups: 6 54 55
VmSize: 298972 kB
VmLck: 0 kB
VmRSS: 31024 kB
VmData: 186292 kB
VmStk: 64 kB
VmExe: 9420 kB
VmLib: 30756 kB
Threads: 2
SigPnd: 0000000000000000
ShdPnd: 0000000000054107
SigBlk: 0000000000000004
SigIgn: 0000000000081000
SigCgt: 0000000197816eff
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

Hi Silviu,

Am Montag 06 M 2006 13:23 schrieb Silviu Marin-Caea:
32001
this might be the PID of the child process that does not exist any more. Mh,
how long does this state persist? Hours? Days?

In worst case, you won't have a chance to get rid of it without booting the
node. As I have explained earlier, a kill signal to a zombie is senseless. A
zombie has already received a signal, otherwise it would be a normal process.

Best regards,

Monday 06 March 2006 14:48, Martin Klier wrote:
Hi Silviu,

Am Montag 06 M 2006 13:23 schrieb Silviu Marin-Caea:
32001

this might be the PID of the child process that does not exist any more.
Mh, how long does this state persist? Hours? Days?

1-2 hours then the buffers go low and the server starts swapping so hard it's
useless. Reboot is the only option.

In worst case, you won't have a chance to get rid of it without booting the
node. As I have explained earlier, a kill signal to a zombie is senseless.
A zombie has already received a signal, otherwise it would be a normal
process.

I tried sending a -SIGCHLD to the parent of this zombie (a java process).
That didn't help. Then, after restarting the java process, the zombie became
child of init. And init could not clean the zombie either.

El Lunes 06 Marzo 2006 14:05, Silviu Marin-Caea :
Monday 06 March 2006 14:48, Martin Klier wrote:
Hi Silviu,

Am Montag 06 M 2006 13:23 schrieb Silviu Marin-Caea:
32001

this might be the PID of the child process that does not exist any more.
Mh, how long does this state persist? Hours? Days?

1-2 hours then the buffers go low and the server starts swapping so hard
it's useless. Reboot is the only option.

In worst case, you won't have a chance to get rid of it without booting
the node. As I have explained earlier, a kill signal to a zombie is
senseless. A zombie has already received a signal, otherwise it would be
a normal process.

I tried sending a -SIGCHLD to the parent of this zombie (a java process).
That didn't help. Then, after restarting the java process, the zombie
became child of init. And init could not clean the zombie either.

Upgrade your kernel to a never version or recompile the existing one
otherwise you will see zombies, even, in your best dreams ;-)

Hi,

this may be off topic but maybe you give me a hint anyway.

Is there a way to update a table with unknown column_name?

This means by position not by name.

If i remember correct i read many times something like

update <table_name:1 = 1

thanks, kind regards,

Toni