I can't kill a processus

[malki_3]

I have nightly cron scipt for backup
Yesterday I have tow process fbackuprdr blocked.
I have ejecting a tape and I have doing a fbackup testwithout problem.
But the tow script still blocked on the system because I can't kill them.
This morning I have the similary problem.
Now I have 4 fbackuprdr provcess blocked..
ps -ef|grep fback
root 16126 1 0 juin 4 ? 5:56 /usr/sbin/fbackuprdr 270851 1 262144 fr_FR.iso88591 0 0
root 9028 1 0 23:04:36 ? 5:49 /usr/sbin/fbackuprdr 73220 1 262144 fr_FR.iso88591 0 0
root 16125 1 0 juin 4 ? 5:57 /usr/sbin/fbackuprdr 270851 0 262144 fr_FR.iso88591 0 0
root 9027 1 0 23:04:36 ? 6:01 /usr/sbin/fbackuprdr 73220 0 262144 fr_FR.iso88591 0 0
How van I kill theses process withour restarting the server..
Thanks for your help

[Peter Kloetgen]

Hi Malki,

first of all, get the PPID for your processes, which you can't kill. (use the ps -ef command) After that, you have to kill the processes parent process, normally all child processes die together with parent process. If not, you have a process called "zombie", which you can't kill at all. Then you really have to reboot your system to get rid of them. Sorry for the bad news.

Allways stay on the bright side of life!

Peter

[U.SivaKumar_2]

Hi,
I assume You know which backup device you were using for fbackup.
For example
you backup device is /dev/rmt/0m
To kill the processes attached to tape device
#fuser -k /dev/rmt/0m
Repeat the above command for 5 times.

regards,
U.SivaKumar

[Steve Steel]

Hi

If waiting on reenterant i/o they will not detect the kill signal and thus will not die.

These are reader processes and as such not active on the /dev/rmt/0m

You reported this problem before.

What is the patch level you have for the fbackup cumulative.

Does fbackup log errors anywhere.

You may need to tune your config file.

Check that you have no filesystems in the backup where links cause the backup to loop

Steve Steel

[Paula J Frazer-Campbell]

Hi

Be VERY careful when killing a parent process - check what it is first.

Your parent process is 1 (init) -DO NOT kill this as it will bring your server down.


Paula

[Bill McNAMARA_1]

possibly caused by blocking ioscans..

ps -ef | grep ioscan

just to check.
Bill

[malki_3]

Hi
For Steve
Thanks for your ensewer

I understand that these process are wainting for i/o.
How can I know what's the patch level for the fbackup cumulative.

In the log ther's no error : Tha backup began and ine the end I founf any errorr.

"You may need to tune your config file...??"

Check that you have no filesystems in the backup where links cause the backup to loop

In this last point I don't understant what you want to said

[harry d brown jr]

Use "what /usr/sbin/fbackup" to find the revision, here's TWO examples from two different machines:

[root]pbctst: what /usr/sbin/fbackup
/usr/sbin/fbackup:
$Revision: @(#) all CUP11.11_BL2001_0716 PATCH_11.11 PHCO_23914
Tue Jul 17 11:45:48 PDT 2001 $
[root]pbctst:


# what /usr/sbin/fbackup
/usr/sbin/fbackup:
$Revision: B.11.11_LR
Thu Oct 26 23:41:10 PDT 2000 $
#


live free or die
harry

[harry d brown jr]

What Steve is talking about (backup loop) is to make sure that there is not a link that is referencing a directory ABOVE, as in this symbolic link:

/tmp/hi/tst -> /tmp

live free or die
harry

[Frank Slootweg]

Besides the fbackup (and SAM (if SAM is used to do the backup)) logs, look in the syslogd(1M) log (probably /var/adm/syslog/syslog.log) and the dmesg(1M) log (see the dmesg(1M) manual page on how to setup dmesg in root's crontab). Look for messages with (about) the same date/time as the dates/times of the processes.

[Christian Valet_2]

Him

> Check that you have no filesystems in the backup where links cause the backup to loop

>> In this last point I don't understant what you want to said

He means that if you have a link deep in your filesystem which refer to an upstream directory of the same filesystem, this would
cause your backup to loop indefinitely.

example:
root@peis07_#pwd
/services/Recovery/ignite/archives/doc
root@peis07_#ll -a
total 1
lrwxrw-r-- 1 root sys 18 Jun 7 08:41 loop -> /services/Recovery

Chris