Hi all,

I have some logical disks assigned to my server(RHEL 5.5) from the iSCSI storage for which I have multiple paths. But I am not able to see the correct subpath count as in the file /dev/disk/by-path/ip-192.168.x.x-iscsi-iqn-xxxx

However, when I add the udevtrigger command in /etc/rc.local, I am able to see the correct paths. Can someone please let me know, what udevtrigger exactly does to correct the paths count in /dev/disk/by-path/

Thanks for your help in advance

udevtrigger: Request device events from the kernel. Primarily used to replay events at system coldplug time.

In other words triggers setup of devices based on kernel events, meaning it adds/removes/changes devices nodes (rights, ownership, acl) and links in /dev, based on some pre-existing rules, usually found in /lib/udev/rules.d and /etc/udev/rules.d

Does this mean the devices get refreshed when I type the udevtrigger command. Before running udevtrigger, I get wrong number of devices and after running this command, the number of devices is corrected. Is this some sort of bug on RHEL with iSCSI connections?

Again, the best people to ask about bugs with Red Hat would be Red Hat Support...which you don't have, since you're using 5.5. The last supported version of RHEL 5 is 5.9, and that's only under the extended-support option. There have been NUMEROUS bugs fixed between 5.5 and 6.5, which is why people pay for support/updates of RHEL, or they don't use it.

ISCSI devices aren't handled the same way as other devices are.

Hi TBone,
Thanks for ur help. I do not have RHEL support.
My question is why do I need to run udevtrigger when I have not made any changes in /etc/lib/rules.d/****.rules to make the entries correct in /dev/disk/by-path/...

Then most probably there is a bug which presents itself as not getting ADD/CHANGE kernel events or somehow a broken rule or broken udev. Usually when you run udevtrigger manually is (or should be) based on CHANGE kernel events (by default). This is not 100% sure, as you do have a old version of RH and of course udev.

Trigger can be use for all types of actions, but usually if the ACTION is not mentioned, there is a default, which should be CHANGE, but I'm not 100% sure on this.

OK, udevtrigger version 095 doesn't seem to have the option of change the ACTION, which might mean it will work on any ACTION (change/add).

Basically it means that something doesn't work right (it might be kernel, or iscsi kernel module, or udev)

What you could do is use 'udevtrigger and the udevsettle':

For more info use man:

man udevtrigger
man udevsettle

1 members found this post helpful.

Spell out your words, please. And go back and re-read my last post. RHEL 5.5 is not even AVAILABLE for support...you are MANY versions behind, and any bugs in software like this (and there have been SEVERAL reported), have been fixed. If you don't pay for RHEL, then YOU SHOULD NOT BE USING IT in a production environment. You PAY FOR support/updates/bugfixes...if you don't get them, all you're doing is setting yourself up for dealing with problems like this, that have probably ALREADY BEEN FIXED.
And your question was answered. ISCSI devices aren't typical 'devices', and rescanning manually is often the quickest way to pick them up, just like with a SAN device. The LUN may be presented, but not be VISIBLE until the SAN driver is reloaded/refreshed. And AGAIN, this may also be a bug that has been fixed, and available to you if you PAY FOR RHEL.