device properties and change events

[Keith Pine]

I'm using udev-147 in CentOS 6.3.

I have two rules that import properties into the udev db. I'll use a
simplified example.

IMPORT{program}="program1 %k"
ACTION=="add", IMPORT{program}="program2 %N"

program1 exports MY_FOO, and program2 exports MY_BAR. I've noticed that
when a change event is triggered, MY_BAR is no longer available in the
udev database. So it appears change events clear the existing environment.
The work done in program2 is relatively expensive so I'd rather only run
it when the device is first added.

It looks like I can re-import MY_BAR if I use IMPORT{db} in a separate
rule:

IMPORT{program}="program1 %k"
ACTION=="add", IMPORT{program}="program2 %N"
ACTION=="change", IMPORT{db}="MY_BAR"


Is this the correct approach? Or is there another way to persist the
properties that were imported during add, besides re-importing program2?

Also, is it possible to determine *what* causes a change event to occur?
With 'udevadm monitor' I can see change events being triggered whenever my
application exits (for the devices it has opened), and would like to
determine why. I was hoping udev could give me a hint.

-Keith

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Greg KH]

Post by Keith Pine
I'm using udev-147 in CentOS 6.3.

My sympathies :)

Post by Keith Pine
I have two rules that import properties into the udev db. I'll use a
simplified example.
IMPORT{program}="program1 %k"
ACTION=="add", IMPORT{program}="program2 %N"
program1 exports MY_FOO, and program2 exports MY_BAR. I've noticed that
when a change event is triggered, MY_BAR is no longer available in the
udev database. So it appears change events clear the existing environment.

What is triggering a change event? What type of device? What driver?

Post by Keith Pine
The work done in program2 is relatively expensive so I'd rather only run
it when the device is first added.
It looks like I can re-import MY_BAR if I use IMPORT{db} in a separate
IMPORT{program}="program1 %k"
ACTION=="add", IMPORT{program}="program2 %N"
ACTION=="change", IMPORT{db}="MY_BAR"
Is this the correct approach? Or is there another way to persist the
properties that were imported during add, besides re-importing program2?

I think that is correct. When a device "changes", all of it's
attributes are thrown away as they obviously changed (the kernel told us
so.)

Post by Keith Pine
Also, is it possible to determine *what* causes a change event to occur?

What type of device is this?

Post by Keith Pine
With 'udevadm monitor' I can see change events being triggered whenever my
application exits (for the devices it has opened), and would like to
determine why. I was hoping udev could give me a hint.

Your kernel driver should tell you why, what driver is it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Keith Pine]

-----Original Message-----
Sent: Thursday, March 28, 2013 3:59 PM
To: Keith Pine
Subject: Re: device properties and change events

...

I think that is correct. When a device "changes", all of it's
attributes are thrown away as they obviously changed (the kernel told us
so.)

Ok, that makes sense.

Post by Keith Pine
With 'udevadm monitor' I can see change events being triggered whenever

my

Post by Keith Pine
application exits (for the devices it has opened), and would like to
determine why. I was hoping udev could give me a hint.

Your kernel driver should tell you why, what driver is it?

SCSI block device (sd). Your questions got me looking again, so I did a quick test which showed that the act of closing a file descriptor opened on the block device with write access is enough to trigger the change event (read-only access does not cause a change event). I looked at scsi debug logs, etc., and finally checked Google, where I was reminded about the watch option. Sure enough, the 60-persistent-storage.rules file enables watch for sd devices. If I set nowatch in my custom udev rules the change events no longer trigger; mystery solved.

I guess now I need to consider whether or not I even want watch enabled for my block devices. There's no filesystem and my application will typically be the owner and only user, so I'm not sure the option is useful. Are you aware of any other kind of events that could cause a change event on a block device?

Thanks,
Keith
N�����r��y����b�X��ǧv�^�)޺{.n�+����{���i��"��^n�r���z���h�����&���G���h�