1748259 Members
4022 Online
108760 Solutions
New Discussion юеВ

Re: kill fbackup

 
SOLVED
Go to solution
Dags
Frequent Advisor

kill fbackup

Hi Masters,

Here's what happen, I issued kill -9 to kill fbackup and I think it is now a ghost process, and we can't perform backup anymore. Aside from reboot, is there other way to kill this proccess. I'm using HPUX 11.11 9000/800. Thnaks in advance guys. Sample of ps -ef|grep fbackup:

root 6216 1 0 Nov 7 pts/tk 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf
root 3759 1 0 Nov 7 ? 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf
root 29363 5988 1 10:31:39 pts/11 0:00 grep fbackup
root 2000 1 0 Nov 7 ? 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf
root 12701 20575 0 Nov 7 pts/tk 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf
6 REPLIES 6
Johnson Punniyalingam
Honored Contributor

Re: kill fbackup

>>root 6216 1 0 Nov 7 pts/tk 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf
root 3759 1 0 Nov 7 ? 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf
root 29363 5988 1 10:31:39 pts/11 0:00 grep fbackup
root 2000 1 0 Nov 7 ? 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf
root 12701 20575 0 Nov 7 pts/tk 0:00 /usr/sbin/fbackup -f /dev/rmt/14m -0 -u -v -c /var/adm/fbackupf<<<<<<<<<<<<



I will start with below

kill -9 3759 29363 2000 12701

if not reboot

"ghost" processes you actually mean "zombie" processes. You can't kill them (because they are already dead and can certainly never respond to a signal which is all a kill is). Zombie's consume no resources (other than a process table slot) and do no real harm.
Problems are common to all, but attitude makes the difference
Dags
Frequent Advisor

Re: kill fbackup

Thanks Johnson. I've already done your recommendation.

Any other inputs?
Bill Hassell
Honored Contributor
Solution

Re: kill fbackup

The most iumportant rule is to never use kill -9 for any program! Like many sophisticated programs, fbackup uses shared memory and kill -9 will not allow a normal shutdown. So the large amount of shared memory is permanently unuseable until you reboot or figure out the shared memory segment with ipcs. The correct kill signal is kill -15 possibly followed with a kill -1.

I assume you have issued several kill -9 signals and fbackup does not respond. So the program is hung, waiting on some service from the kernel. Your program will not terminate until the condition causing the hang is removed. Normally, I would expect this kind of a problem with a network backup but the above appears to be a tape backup. Check your syslog.log for hardware errors. Also, are you backing up data from a network filesystem (NFS or CIFS?). Or are you using LUNs from a SAN system? Any of these conditions could cause the program to hang while waiting for the kernel to complete the I/O.

There isn't any way to terminate fbackup until it starts running again. Therefore a reboot is required. This will also remove the shared memory segments that wwere orphaned by fbackup.

kill signals actually do not terminate a program. Instead, the signal (like kill -15) is stored in the program's process table and the program will immediately check the signal. A well writen program (like fbackup) will senes the signal and gracefully shutdown. However, kill -9 cannot be sensed or trapped like other signals. kill -9 will forcefully remove the program without allowing any cleanup for files and shared memory. Use it as a very last resort.


Bill Hassell, sysadmin
Dags
Frequent Advisor

Re: kill fbackup

You're right Bill, I should have done the kill -15 and followed by -1. Lesson learned. Thanks for explaining. I'll do a reboot.
Dennis Handly
Acclaimed Contributor

Re: kill fbackup

>Johnson: "ghost" processes you actually mean zombie processes. You can't kill them

These are hung processes, not zombies. And you can kill zombies by killing the zombie master.

Johnson Punniyalingam
Honored Contributor

Re: kill fbackup

Noted Many Thanks <>
Problems are common to all, but attitude makes the difference