Removing Stale H/W paths (without device files) without Rebooting

[Project Team]

We have a production system running HP-UX 11.23 which is SAN attached. We have had numerous problems with a MSL5000 backup library and as such recabled and moved a few things around. The issue now is that the HP-UX box cannot see the library or tape drives.

We believe it is because there are stale hardware paths still on the server - these paths are wrong, but we cannot remove them either. As this is a production box, a reboot is really not feasible, so we need a way of removing these paths manually.

We have tried the 'rmsf' command, but with no luck - please see attached.

Please help as we are not getting any backups to tape at present.

[Duncan Edmonstone]

The devices are probably staying cos there are device files associated with them in /dev

Find all devices in /dev that point to nothing by doing:

find /dev -type c -exec lssf {} \; | grep '???'
find /dev -type b -exec lssf {} \; | grep '???'

Any of these you find should be removed - try rmsf first - if that doesn't get rid of it just use rm.

After you've gotten rid of them all re-run your ioscan - have the devices now gone?

HTH

Duncan

[Kent Ostby]

Project Team --

It's quite possible that the reverse is the problem -- that you've moved the devices and DONT have device files for them all.

I would suggest you do:

insf -e

And then check your ioscan.

Best regards,

Oz

[RolandH]

You should try this

# rmsf -k -H 1/0/8/1/0/200.0.255.0.0.0

If the Hardware is already there with the status NO_HW, the device driver for that hardware does not support the unbind option. All you can do then is to reboot.

Roland

[Project Team]

Gents,

As my UNIX guru is not available this afternoon, I will not be able to give you an immediate update, but thankyou for all the input so far.

I did try the insf -e command (see attachments) on a test machine that we have replicated the problem on. But I am not really qualified to delete (and scared!)

However, I do get the feeling that the only way we can do this is with a reboot!

Watch this space!!

Cheers
JP

[TwoProc]

JP,
Rather risk your uptime, company, career etc - why not call HP and ask for someone in their consulting group to "come on down" and fix your system. That service is available for a fee that you should be willing to justify.

[TwoProc]

JP,
Rather risk your uptime, company, career etc - why not call HP and ask for someone in their consulting group to "come on down" and fix your system. That service is available for a fee that you should be willing to justify. I really hate hearing that you're uncomfortable doing this, and I don't want to see you get into a mess that you can't handle at this time.

[Rita C Workman]

Your MSL5000 is SAN attached.
You said you 'recabled' and 'moved things around'. hmmm

Your SAN attached so, it is going through a switch. So I might ask a couple questions:

What was moved? from where - to where? (and I'm referring to ports here)
What effect would this have on your SAN zoning ? If changes were going to be necessary, .. were they done ? were they done right ?

Just a thought,
Rita

[Project Team]

OK!

I'm not a unix guy, hence why I will wait till Monday for the right guy to look through all the suggestions here before anything is done.

Regarding the SAN and the MSL5000 - we have 2 NSR's in the MSL50262 so that we can even out the many single SAN attached servers we have across the 2 fabrics. What was changed - a long story but the here's the short version - I like things a certain way, NSR1 was plugged into SAN Switch 2, and NSR2 into SAN Switch 1. We also have had some issues with NSR2/Drive2 (as I said long story). Now we have NSR1 in switch 1 and so on (my tidy mind).

Yes the cabling and zoning has been done right. The library and drives has been successfully presented to a test server and all is as you would expected.

The problem we have on the production system is that the Stale H/W paths are when the MSL was down path NSR1 in switch 2. Now the MSL is actually down path NSR1 in switch 1.

We think that the server cannot pickup the MSL because of the old "stale" path still held in memory and hence the request on how to remove without a reboot!

Also, this is only our theory as we can think of no other reason why the server does not recognise the MSL and Drives. So we need to prove or disprove!

Thanks for all you input today gents! Much appreciated.

Regards
JP