AIX

I issued
fuser -k -x -u ./amqcc_r

It brought down the whole box
The unix admin says if I had issued
fuser -k -x -u amqcc_r then it would have not brouht down the box.

Does it make sense to you guys

Sounds silly to me.

Did you check errpt?
Did you get a sysdump?
Did you get a core file?
Did you call IBM?

...
Did you get some errorcode on the LED-display or its respective successors (HMC, ...)?

Me too. I don't think your issuing "fuser" really brought down the box. Maybe it was just coincidence and they are looking for someone to lay the blame on.

bakunin

I tried it on a test box and that brought down the box too. I did open a PMR.
I don't have access to check the LED or go to the actual physical box.

Could you please give some additional data? I'll give the commands you could issue to determine what I'm interested in along with some sample output:

*) Maintenance level and OS

Code:

root@foobar:/ # instfix -i | grep "AIX_ML"
    All filesets for 5.1.0.0_AIX_ML were found.
    All filesets for 5100-01_AIX_ML were found.
    All filesets for 5100-02_AIX_ML were found.
    All filesets for 5100-03_AIX_ML were found.
    All filesets for 5100-04_AIX_ML were found.
    All filesets for 5100-05_AIX_ML were found.
    All filesets for 5100-06_AIX_ML were found.

*) Level of bos.rte.filesystem (the fileset containing fuser)

Code:

root@foobar:/ # lslpp -w /usr/sbin/fuser
  File                                        Fileset               Type
  ----------------------------------------------------------------------------
  /usr/sbin/fuser                             bos.rte.filesystem    File
root@foobar:/ # lslpp -l bos.rte.filesystem
  Fileset                      Level  State      Description         
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.rte.filesystem        5.1.0.57  COMMITTED  Filesystem Administration

Path: /etc/objrepos
  bos.rte.filesystem        5.1.0.57  COMMITTED  Filesystem Administration

What you could also do is to analyse the dump the machine has written:

First, find out your dump device and make sure it is big enough to hold the dump: "sysdumpdev -e" gives an estimate how big the dump will be. Multiply that by at least 2 (out of pure paranoia and just to be on the save side). The dump will be written to the paging space so make sure it is big enough to hold that amount. During the following system startup the dump will be copied from the paging space to the designated dump-device, the manual only says it has to be a filesystem, but it hast to be in the rootvg too. Issue a "sysdumpdev -s <fs>" then to designate this location as the target device to copy the dump to at the reboot following the dump.

You could then use kdb (kernel debugger) to analyse the dump written.

bakunin

The command you issued:

fuser -k -u -x ./file

Should not matter whether you run it with ./ or not, the command kills all processes running on that filesystem. So assuming the file was on a file system with OS commands running then you would of brought the box down.

Hope this helps.