How to stop a program

[jcmraats]

How to stop icecast:


PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
3604 jack 11 0 0 100M 19M uwrlck 1 0:06 0.02% icecast

kill 3604 doesn't wok
killall icecast doesn't work.

Please help!

 

[nxjoseph@]

Maybe $ kill -9 <pid> works?

 

[jcmraats]

Thank you. That works!

 

[mer]

"man kill"
kill sends a signal to the process; I think default is SIGTERM. If a process is not in position to actually accept and process signals (no signal handler, blocked somewhere) the default does not work.
"kill -9" as superuser is "KILL (non-catchable, non-ignorable kill)" so basically handled at the system level, not handled by the process itself.

"kill" with no signo lets the process gracefully shutdown.
"kill -9" is roughly "pull the power on the process"

 

[MG]

"man kill"
kill sends a signal to the process; I think default is SIGTERM. If a process is not in position to actually accept and process signals (no signal handler, blocked somewhere) the default does not work.
"kill -9" as superuser is "KILL (non-catchable, non-ignorable kill)" so basically handled at the system level, not handled by the process itself.

"kill" with no signo lets the process gracefully shutdown.
"kill -9" is roughly "pull the power on the process"

I remember umount being unresponsive and not willing to terminate. Also firefox while it was somehow running an internal routine that prevents it from getting killed until it's finished. It's not arbitrary, I think. Zombie processes and such can happen. Kill doesn't always work.

 

[gpw928]

Using SIGKILL kill -9 <pid> exercises extreme prejudice. The process never knows that it died. That's really bad for any process that needs to maintain external state.

SIGTERM (signal 15) was invented for the precise purpose of terminating a process politely. Any process that cares about maintaining external state will catch the signal, tidy up, and exit gracefully. SIGHUP, SIGINT, and SIGQUIT (signals 1, 2, and 3) are generally processed in the same way.

I have seen signal 9 profoundly misused in professional circumstances, in what amounted to breathtaking stupidity. Never use it routinely, and never use it unless you precisely understand the damage it can do.

 

[gpw928]

Zombie processes and such can happen. Kill doesn't always work.

Zombie processes consist solely of an entry in the process table containing the exit status of a process that has already terminated. That entry exists so that the parent of the terminated process can execute a wait(2) system call (to collect the exit status). You can not kill a zombie process. There is nothing to kill.

 

[cracauer@]

Processes will not exit on signal 9 when they are stuck in the kernel. umount is a good example of a program that can happen to.

 

[atax1a]

signal 9 is the big gun. we start with kill, which defaults to SIGTERM, and if that doesn't work, move to kill -INT and then kill -QUIT and only after all those have failed do we move to signal 9.

 

[MG]

Zombie processes consist solely of an entry in the process table containing the exit status of a process that has already terminated. That entry exists so that the parent of the terminated process can execute a wait(2) system call (to collect the exit status). You can not kill a zombie process. There is nothing to kill.

Free the process memory that's shown by top and ps and remove the entry? What's still under that PID and why isn't it taken care of?

 

[cracauer@]

Free the process memory that's shown by top and ps and remove the entry? What's still under that PID and why isn't it taken care of?

The actual memory mappings that the program did are gone when it is a zombie. There should only be minor stuff left.

Zombies are always the fault of the process that originally started the later zombie.

 

[MG]

The actual memory mappings that the program did are gone when it is a zombie. There should only be minor stuff left.

Zombies are always the fault of the process that originally started the later zombie.

But something is irreversible, it seems. If a process reaches this state, the process management is no longer capable of removing all related references to it like usual when something just exits with 0.

 

[cracauer@]

But something is irreversible, it seems. If a process reaches this state, the process management is no longer capable of removing all related references to it like usual when something just exits with 0.

Yeah but they are too small to matter. Unless you recursively create an infinite number of them or something.

 

[atax1a]

in a later unix they should make zamboni processes. i have no idea what this would do

 

[gpw928]

But something is irreversible, it seems. If a process reaches this state, the process management is no longer capable of removing all related references to it like usual when something just exits with 0.

The only resources consumed by a zombie process is an entry in the kernel's process table. That entry contains the exit status of the zombie process. That exit status must be preserved so that the parent process can collect the exit status of the child process. If the parent never wait(2)s, then the zombie must remain. It's not a bug. It's a design feature.

 

[MG]

The only resources consumed by a zombie process is an entry in the kernel's process table. That entry contains the exit status of the zombie process. That exit status must be preserved so that the parent process can collect the exit status of the child process. If the parent never wait(2)s, then the zombie must remain. It's not a bug. It's a design feature.

But there's no mechanism that finds that out and clears the process remains?
It feels like lack of integrity. The OS can't return to a clean state without reboot?

How is such process still shown as using memory? Is this malloc() not remembering for who particular allocations were?

 

[hruodr]

signal 9 is the big gun. we start with kill, which defaults to SIGTERM, and if that doesn't work, move to kill -INT and then kill -QUIT and only after all those have failed do we move to signal 9.

Is "kill -9" murder?

 

[mer]

Using SIGKILL kill -9 <pid> exercises extreme prejudice. The process never knows that it died. That's really bad for any process that needs to maintain external state.

SIGTERM (signal 15) was invented for the precise purpose of terminating a process politely. Any process that cares about maintaining external state will catch the signal, tidy up, and exit gracefully. SIGHUP, SIGINT, and SIGQUIT (signals 1, 2, and 3) are generally processed in the same way.

I have seen signal 9 profoundly misused in professional circumstances, in what amounted to breathtaking stupidity. Never use it routinely, and never use it unless you precisely understand the damage it can do.

Yep, that's why I used the analogy of "pulling power".
I have also seen it misused

 

[mer]

Is "kill -9" murder?

That is funny.

 

[cracauer@]

But there's no mechanism that finds that out and clears the process remains?
It feels like lack of integrity. The OS can't return to a clean state without reboot?

You can always kill the parent of the zombie. In which case the zombies goes to init, which consumes it.

You can't eliminate a zombies without doing that since the parent still has business to do with its child.

How is such process still shown as using memory? Is this malloc() not remembering for who particular allocations were?

It shouldn't be significant memory. What do you see in top(1)?

 

[MG]

You can always kill the parent of the zombie. In which case the zombies goes to init, which consumes it.

You can't eliminate a zombies without doing that since the parent still has business to do with its child.



It shouldn't be significant memory. What do you see in top(1)?

I don't remember but less than 1MB and not changing. Seen this only a few times. I noticed the problem while testing something that uses mount and umount and leave no trace of it. Dead umounts were stacking up after a few runs. Not a very big deal but I wonder what causses it. The process management not being able to get rid of something from the past sounds significant to security.

It must be possible to make umount believe it finished succesfully by setting some bytes in the process space as root...

 

[atax1a]

I don't remember but less than 1MB and not changing. Seen this only a few times. I noticed the problem while testing something that uses mount and umount and leave no trace of it. Dead umounts were stacking up after a few runs. Not a very big deal but I wonder what causses it. The process management not being able to get rid of something from the past sounds significant to security.

It must be possible to make umount believe it finished succesfully by setting some bytes in the process space as root...

no, the zombie process has no security effect outside of the process-table entry (it has no running code!), and the only way to remediate it is to have the parent process either exit, and thus have the zombies reaped by init, or have the parent process properly wait.

 

[cracauer@]

I don't remember but less than 1MB and not changing. Seen this only a few times. I noticed the problem while testing something that uses mount and umount and leave no trace of it. Dead umounts were stacking up after a few runs. Not a very big deal but I wonder what causses it. The process management not being able to get rid of something from the past sounds significant to security.

It must be possible to make umount believe it finished succesfully by setting some bytes in the process space as root...

umounts?

Are you sure these were zombies?

Sounds more like ordinary processes hung in the kernel. Those take up their original space.

 

[MG]

umounts?

Are you sure these were zombies?

Sounds more like ordinary processes hung in the kernel. Those take up their original space.

I think it was in 14.2, my previous main system. Something couldn't unmount but the parent process didn't exist anymore. I probably caused it myself. No idea how I fixed it but I remember being entirely unable to remove it except with reboot. I could re-run the scripts that caused it. The existing umount process was ignored and a new 1 initiated on the same target. If I notice this happening again, I'll make a screendump for a thread.

 

[cracauer@]

I think it was in 14.2, my previous main system. Something couldn't unmount but the parent process didn't exist anymore. I probably caused it myself. No idea how I fixed it but I remember being entirely unable to remove it except with reboot. I could re-run the scripts that caused it. The existing umount process was ignored and a new 1 initiated on the same target. If I notice this happening again, I'll make a screendump for a thread.

If the parent isn't around anymore it cannot be a zombie. It would be collected by init.

You had an ordinary hang.