Hello,

I want to call a script after I plugged my USB scanner. I use udev for thisby
adding a rule

rd@blackbox:/etc/udev/rules.d$ cat z_local.rules
SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
rd@blackbox:/etc/udev/rules.d$

This calls then the umax1220u script:

rd@blackbox:/usr/local/bin$ cat umax1220u
#!/bin/sh
set -vx
# example for a DEVICE: /proc/bus/usb/001/004

echo umax1220u $DEVICE $* >> /tmp/usb.log
export >> /tmp/usb.log
ACTION=$1

# if [ -z $DEVICE ]; then exit 0; fi

case $ACTION in
start)
echo "UMAX 1220u scanner added"
# DEV=umax1220u:libusb:`echo $DEVICE|cut -d / -f 5`:`echo $DEVICE|
cut -d / -f 6`
DEV=`scanimage -L|cut -f 2 -d \\\`|cut -f1 -d \'`
echo started: $DEV >> /tmp/usb.log
# example for a DEV umax1220u:libusb:001:006
(sleep 20
&& /usr/bin/scanimage --lamp-off --device=$DEV --dont-scan) &
;;
stop)
echo "UMAX 1220u scanner removed"
;;
esac
rd@blackbox:/usr/local/bin$

When I plug my scanner with this config, it seems an infinite number of
umax1220u scripts are started in a sequence (i.e. not in parallel, when one
is completed the next one starts).

Initial analysis shows that scanimage causes in syslog

Apr 22 22:07:48 blackbox kernel: ppdev0: registered pardevice
Apr 22 22:07:48 blackbox kernel: ppdev0: unregistered pardevice
Apr 22 22:07:50 blackbox kernel: ppdev0: registered pardevice
Apr 22 22:07:50 blackbox kernel: ppdev0: unregistered pardevice

This might then kick off another umax1220u via udev (?). An this would then
loop.

Does anybody know how I could get rid of this event?

Does anybody know a better way to get the script started which switches the
scanner lamp off?

Thanks,
Rainer

--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/

Hello,

On Apr 22 22:18 Rainer Dorsch wrote (shortened):
> I want to call a script after I plugged my USB scanner. I use udev for this by
> adding a rule
....
> SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
> GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
....
> When I plug my scanner with this config, it seems an infinite number of
> umax1220u scripts are started in a sequence (i.e. not in parallel, when one
> is completed the next one starts).

It seems you need a test if ACTION!="add", i.e. a rule like

ACTION!="add", GOTO="end"
SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", ... RUN+="..."
LABEL="end"


I had a similar issue but I got it run only about 5 times
with a rule like

ACTION!="add", GOTO="end"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", RUN+="..."
LABEL="end"

Fortunately in my case what is run is idempotent so that
it doesn't matter when it is run about 5 times.
I don't know the root cause, I guess it is the usual udev crap.

Welcome in the hell of udev, HAL and whatever else sophisticated
stuff which is required to make users happy or so they say...


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Johannes Meixner <jsmeix@suse.de> wrote:

Hi,

>> umax1220u scripts are started in a sequence (i.e. not in parallel, when one
>> is completed the next one starts).

When troubleshooting udev rules, use udevmonitor to actually see
what's happening in terms of udev events and their properties.

> ACTION!="add", GOTO="end"
> SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", RUN+="..."
> LABEL="end"

Be careful with the labels you use. Always use a unique label name, or
you're asking for troubles. (been there, done that, accidentally
rendered a number of systems unbootable due to that ...)

> Welcome in the hell of udev, HAL and whatever else sophisticated
> stuff which is required to make users happy or so they say...

<aol />

JB.

--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Am Mittwoch, 23. April 2008 schrieb Julien BLACHE:
> Johannes Meixner <jsmeix@suse.de> wrote:
>
> Hi,
>
> >> umax1220u scripts are started in a sequence (i.e. not in parallel, when
> >> one is completed the next one starts).
>
> When troubleshooting udev rules, use udevmonitor to actually see
> what's happening in terms of udev events and their properties.
>

That was a very good hint, thanks. A single scanimage -L causes these events:

UEVENT[1208979136.171525] remove /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UEVENT[1208979136.171696] remove /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UEVENT[1208979136.171702] remove /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)
UEVENT[1208979136.171707] add /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UEVENT[1208979136.171712] add /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UEVENT[1208979136.171717] add /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)
UDEV [1208979136.172276] remove /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UDEV [1208979136.172803] remove /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UDEV [1208979136.173239] remove /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)
UDEV [1208979136.174020] add /class/usb_endpoint/usbdev1.5_ep01
(usb_endpoint)
UDEV [1208979136.174831] add /class/usb_endpoint/usbdev1.5_ep82
(usb_endpoint)
UDEV [1208979136.175619] add /class/usb_endpoint/usbdev1.5_ep83
(usb_endpoint)

>
> > ACTION!="add", GOTO="end"
> > SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", RUN+="..."
> > LABEL="end"
>
> Be careful with the labels you use. Always use a unique label name, or
> you're asking for troubles. (been there, done that, accidentally
> rendered a number of systems unbootable due to that ...)

I tried that before after I saw the z60_libsane.rules

ACTION!="add", GOTO="post_lamp_off"
SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
ENV{lamp_off}="yes"
LABEL="post_lamp_off"

But given the events, it is obvious not surprising that this is not working.

> > Welcome in the hell of udev, HAL and whatever else sophisticated
> > stuff which is required to make users happy or so they say...
>
> <aol />

I added now in my script a file system lock:

if [ ! -e /tmp/umax1220u-plugged ]; then

touch /tmp/umax1220u-plugged

Is anybody aware of a more elegant solution for this problem?

Thanks,
Rainer


--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/

Hello,

On Apr 23 22:53 Rainer Dorsch wrote:
> Am Mittwoch, 23. April 2008 schrieb Julien BLACHE:
> > Johannes Meixner <jsmeix@suse.de> wrote:
> >
> > Hi,
> >
> > >> umax1220u scripts are started in a sequence (i.e. not in parallel, when
> > >> one is completed the next one starts).
> >
> > When troubleshooting udev rules, use udevmonitor to actually see
> > what's happening in terms of udev events and their properties.
> >
>
> That was a very good hint, thanks. A single scanimage -L causes these events:
>
> UEVENT[1208979136.171525] remove /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UEVENT[1208979136.171696] remove /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UEVENT[1208979136.171702] remove /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)
> UEVENT[1208979136.171707] add /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UEVENT[1208979136.171712] add /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UEVENT[1208979136.171717] add /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)
> UDEV [1208979136.172276] remove /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UDEV [1208979136.172803] remove /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UDEV [1208979136.173239] remove /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)
> UDEV [1208979136.174020] add /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UDEV [1208979136.174831] add /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UDEV [1208979136.175619] add /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)

I wonder how "scanimage -L" causes any add or remove event at all.
I cannot imagine that those add or remove events are the
same add or remove events which happen when the device
is plugged-in at the USB or plugged-off from the USB.

Do you know what those different usb_endpoints are?
Perhaps the different USB interfaces for the one USB device?

I wonder how one could specify a udev rule which matches
to the one "add" event for the one USB device instead of
whatever bulk of "add" events for whatever stuff which
is related to the one USB device.


> > > ACTION!="add", GOTO="end"
> > > SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", RUN+="..."
> > > LABEL="end"
> >
> > Be careful with the labels you use. Always use a unique label name, or
> > you're asking for troubles. (been there, done that, accidentally
> > rendered a number of systems unbootable due to that ...)

Many thanks for this enlightening info!
Impressive: A thoroughly thought out fail-safe design!

Actually - just because of a queasy feeling - I used
ACTION!="add", GOTO="sane_backends_autoconfig_rules_end"

Of course "man udev" does not mention that all labels
in all udev rules files must be unique.

I can only guess that what udev actually does is to
concatenate all udev rules files into one single set
of rules and then it is not surprising when arbitrary
nonsense happens depending on which individual udev rules
files exist on a particular system which depends on which
individual software packages are installed on this system.

Very nice to debug!
Very easy to others!
Makes all users very happy of course - or so they say.


> I tried that before after I saw the z60_libsane.rules
>
> ACTION!="add", GOTO="post_lamp_off"
> SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
> GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
> ENV{lamp_off}="yes"
> LABEL="post_lamp_off"
>
> But given the events, it is obvious not surprising that this is not working.
>
> > > Welcome in the hell of udev, HAL and whatever else sophisticated
> > > stuff which is required to make users happy or so they say...
> >
> > <aol />
>
> I added now in my script a file system lock:
>
> if [ ! -e /tmp/umax1220u-plugged ]; then
>
> touch /tmp/umax1220u-plugged
>
> Is anybody aware of a more elegant solution for this problem?

You cannot have "udev" and "elegant" at the same time
and you cannot have "HAL" and "elegant" at the same time.

Just do whatever dirty hack fits at the moment for you
and be prepared that next version is sufficiently different
so that your stuff does no longer work.
Then just do whatever other dirty hack and so on ad nauseam
which makes you happy of course or so they say...


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Johannes,

Am Donnerstag, 24. April 2008 schrieb Johannes Meixner:
> Hello,
>
> On Apr 23 22:53 Rainer Dorsch wrote:
> > Am Mittwoch, 23. April 2008 schrieb Julien BLACHE:
> > > Johannes Meixner <jsmeix@suse.de> wrote:
> > >
> > > Hi,
> > >
> > > >> umax1220u scripts are started in a sequence (i.e. not in parallel,
> > > >> when one is completed the next one starts).
> > >
> > > When troubleshooting udev rules, use udevmonitor to actually see
> > > what's happening in terms of udev events and their properties.
> >
> > That was a very good hint, thanks. A single scanimage -L causes these
> > events:
> >
> > UEVENT[1208979136.171525] remove /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UEVENT[1208979136.171696] remove /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UEVENT[1208979136.171702] remove /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
> > UEVENT[1208979136.171707] add /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UEVENT[1208979136.171712] add /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UEVENT[1208979136.171717] add /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
> > UDEV [1208979136.172276] remove /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UDEV [1208979136.172803] remove /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UDEV [1208979136.173239] remove /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
> > UDEV [1208979136.174020] add /class/usb_endpoint/usbdev1.5_ep01
> > (usb_endpoint)
> > UDEV [1208979136.174831] add /class/usb_endpoint/usbdev1.5_ep82
> > (usb_endpoint)
> > UDEV [1208979136.175619] add /class/usb_endpoint/usbdev1.5_ep83
> > (usb_endpoint)
>
> I wonder how "scanimage -L" causes any add or remove event at all.
> I cannot imagine that those add or remove events are the
> same add or remove events which happen when the device
> is plugged-in at the USB or plugged-off from the USB.

Judging from the udevmonitor output it seems they are at least very similar.
Apparently the /class/usb_endpoint/usbdev1.6_ep00 is not included in the
events of the scanimage call but it is included when I replug the device.

This is the output of udevmonitor when replugging the device (commented out
the udev rule which calls the script with scanimage):

UEVENT[1209064961.290600] remove /class/usb_endpoint/usbdev1.6_ep01
(usb_endpoint)
UEVENT[1209064961.290627] remove /class/usb_endpoint/usbdev1.6_ep82
(usb_endpoint)
UEVENT[1209064961.290633] remove /class/usb_endpoint/usbdev1.6_ep83
(usb_endpoint)
UEVENT[1209064961.290638]
remove /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UEVENT[1209064961.290643] remove /class/usb_device/usbdev1.6 (usb_device)
UEVENT[1209064961.290648] remove /class/usb_endpoint/usbdev1.6_ep00
(usb_endpoint)
UEVENT[1209064961.290653] remove /devices/pci0000:00/0000:00:1a.0/usb1/1-1
(usb)
UDEV [1209064961.291029] remove /class/usb_endpoint/usbdev1.6_ep01
(usb_endpoint)
UDEV [1209064961.291540] remove /class/usb_endpoint/usbdev1.6_ep82
(usb_endpoint)
UDEV [1209064961.291973] remove /class/usb_endpoint/usbdev1.6_ep83
(usb_endpoint)
UDEV [1209064961.292349]
remove /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UDEV [1209064961.292882] remove /class/usb_device/usbdev1.6 (usb_device)
UDEV [1209064961.293363] remove /class/usb_endpoint/usbdev1.6_ep00
(usb_endpoint)
UEVENT[1209064965.393967] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1
(usb)
UEVENT[1209064965.394013] add /class/usb_endpoint/usbdev1.7_ep00
(usb_endpoint)
UEVENT[1209064965.398030]
add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UEVENT[1209064965.398042] add /class/usb_endpoint/usbdev1.7_ep01
(usb_endpoint)
UEVENT[1209064965.398048] add /class/usb_endpoint/usbdev1.7_ep82
(usb_endpoint)
UEVENT[1209064965.398053] add /class/usb_endpoint/usbdev1.7_ep83
(usb_endpoint)
UEVENT[1209064965.398058] add /class/usb_device/usbdev1.7 (usb_device)
UDEV [1209064965.399964] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1
(usb)
UDEV [1209064965.401533] add /class/usb_endpoint/usbdev1.7_ep00
(usb_endpoint)
UDEV [1209064965.401976]
add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0 (usb)
UDEV [1209064965.437713] add /class/usb_endpoint/usbdev1.7_ep01
(usb_endpoint)
UDEV [1209064965.437730] add /class/usb_endpoint/usbdev1.7_ep82
(usb_endpoint)
UDEV [1209064965.437736] add /class/usb_endpoint/usbdev1.7_ep83
(usb_endpoint)
UDEV [1209064965.448441] add /class/usb_device/usbdev1.7 (usb_device)

These are the events from a scanimage -L:

UEVENT[1209064997.544063] remove /class/usb_endpoint/usbdev1.7_ep01
(usb_endpoint)
UEVENT[1209064997.544262] remove /class/usb_endpoint/usbdev1.7_ep82
(usb_endpoint)
UEVENT[1209064997.544301] remove /class/usb_endpoint/usbdev1.7_ep83
(usb_endpoint)
UEVENT[1209064997.544337] add /class/usb_endpoint/usbdev1.7_ep01
(usb_endpoint)
UEVENT[1209064997.544372] add /class/usb_endpoint/usbdev1.7_ep82
(usb_endpoint)
UEVENT[1209064997.544407] add /class/usb_endpoint/usbdev1.7_ep83
(usb_endpoint)
UDEV [1209064997.544770] remove /class/usb_endpoint/usbdev1.7_ep01
(usb_endpoint)
UDEV [1209064997.545279] remove /class/usb_endpoint/usbdev1.7_ep82
(usb_endpoint)
UDEV [1209064997.545703] remove /class/usb_endpoint/usbdev1.7_ep83
(usb_endpoint)
UDEV [1209064997.546444] add /class/usb_endpoint/usbdev1.7_ep01
(usb_endpoint)
UDEV [1209064997.547276] add /class/usb_endpoint/usbdev1.7_ep82
(usb_endpoint)
UDEV [1209064997.547997] add /class/usb_endpoint/usbdev1.7_ep83
(usb_endpoint)


> Do you know what those different usb_endpoints are?
> Perhaps the different USB interfaces for the one USB device?

I have no idea, sorry.

> I wonder how one could specify a udev rule which matches
> to the one "add" event for the one USB device instead of
> whatever bulk of "add" events for whatever stuff which
> is related to the one USB device.

That is a good point.

ENV{DEVPATH}=="/class/usb_endpoint/usbdev1.6_ep00", SYSFS{idVendor}=="1606",
SYSFS{idProduct}=="0010", MODE="0664", GROUP="scanner", NAME="umax%n",
RUN+="/usr/local/bin/umax1220\

has the problem that it does not match the usb device (1.6 in this example).

ENV{DEVNAME}=="/dev/umax00", SYSFS{idVendor}=="1606",
SYSFS{idProduct}=="0010", MODE="0664", GROUP="scanner", NAME="umax%n",
RUN+="/usr/local/bin/umax1220u start", ENV{lamp_off}\
="yes"

did not work, although the umax00 corresponds to the device id ep00. Not sure
if that is not yet know in the rules file.

Having in the umax1220u script a condition

if echo $DEVPATH |grep ep00 > /dev/null ; then

works well and I like this a little better than the lock file hack.

To make it robust for future udev releases: Is there any estimate if DEVNAME
or DEVPATH is less likely to change in future udev releases?

> > > > ACTION!="add", GOTO="end"
> > > > SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", RUN+="..."
> > > > LABEL="end"
> > >
> > > Be careful with the labels you use. Always use a unique label name, or
> > > you're asking for troubles. (been there, done that, accidentally
> > > rendered a number of systems unbootable due to that ...)
>
> Many thanks for this enlightening info!
> Impressive: A thoroughly thought out fail-safe design!
>
> Actually - just because of a queasy feeling - I used
> ACTION!="add", GOTO="sane_backends_autoconfig_rules_end"
>
> Of course "man udev" does not mention that all labels
> in all udev rules files must be unique.
>
> I can only guess that what udev actually does is to
> concatenate all udev rules files into one single set
> of rules and then it is not surprising when arbitrary
> nonsense happens depending on which individual udev rules
> files exist on a particular system which depends on which
> individual software packages are installed on this system.
>
> Very nice to debug!
> Very easy to others!
> Makes all users very happy of course - or so they say.
>
> > I tried that before after I saw the z60_libsane.rules
> >
> > ACTION!="add", GOTO="post_lamp_off"
> > SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
> > GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
> > ENV{lamp_off}="yes"
> > LABEL="post_lamp_off"
> >
> > But given the events, it is obvious not surprising that this is not
> > working.
> >
> > > > Welcome in the hell of udev, HAL and whatever else sophisticated
> > > > stuff which is required to make users happy or so they say...
> > >
> > > <aol />
> >
> > I added now in my script a file system lock:
> >
> > if [ ! -e /tmp/umax1220u-plugged ]; then
> >
> > touch /tmp/umax1220u-plugged
> >
> > Is anybody aware of a more elegant solution for this problem?
>
> You cannot have "udev" and "elegant" at the same time
> and you cannot have "HAL" and "elegant" at the same time.
>
> Just do whatever dirty hack fits at the moment for you
> and be prepared that next version is sufficiently different
> so that your stuff does no longer work.

I confirm that this area broke at least two times for me :-(

Rainer

> Then just do whatever other dirty hack and so on ad nauseam
> which makes you happy of course or so they say...
>
>
> Kind Regards
> Johannes Meixner



--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/

Johannes Meixner <jsmeix@suse.de> wrote:

Hi,

>> > Be careful with the labels you use. Always use a unique label name, or
>> > you're asking for troubles. (been there, done that, accidentally
>> > rendered a number of systems unbootable due to that ...)
>
> Many thanks for this enlightening info!
> Impressive: A thoroughly thought out fail-safe design!

udev is an incredible piece of crap, but the good news is that this
piece of crap is mostly stable those days. Which is a big step forward
already.

(and I'll refrain from saying anything at all about the genius who
invented udev. I'll just mention that he's also the author of "stable
API is a nonsense".)

> I can only guess that what udev actually does is to
> concatenate all udev rules files into one single set
> of rules and then it is not surprising when arbitrary
> nonsense happens depending on which individual udev rules
> files exist on a particular system which depends on which
> individual software packages are installed on this system.

You got it.

> Very nice to debug!

deWHAT?

>> I tried that before after I saw the z60_libsane.rules
>>
>> ACTION!="add", GOTO="post_lamp_off"
>> SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
>> GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
>> ENV{lamp_off}="yes"
>> LABEL="post_lamp_off"
>>
>> But given the events, it is obvious not surprising that this is not working.

>> Is anybody aware of a more elegant solution for this problem?

You need to copy a bit more than that from. See the top of the file,
there's more to it than that, also the way to identify a USB device
event changed starting with 2.6.22 and the rules are
backward-compatible in this respect too.

> You cannot have "udev" and "elegant" at the same time

Actually, you can, but you need a bit of udev/uevent knowledge and
some time on your hands.

> and you cannot have "HAL" and "elegant" at the same time.

It's all HALegant, pff.


Welcome to udev-land, Johannes!

JB.

--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hello,

On Apr 24 22:45 Julien BLACHE wrote (shortened):
> udev is an incredible piece of crap, but the good news is that this
> piece of crap is mostly stable those days. Which is a big step forward
> already.
>
> (and I'll refrain from saying anything at all about the genius who
> invented udev. I'll just mention that he's also the author of "stable
> API is a nonsense".)

There he makes it very clear that
"The kernel to userspace interface is the one that
application programs use, the syscall interface.
That interface is _very_ stable over time,
and will not break."

But this is in "stark contrast" to the interface of udev
(i.e. the syntax and keywords how to specify udev rules)
for applications (e.g. SANE) which provide udev rules
and for a normal user udev is completely unusable.

It seems one must talk to udev in terms of internal kernel
values (e.g. internal kernel event names and so on) instead of
a more abstract and therefore more stable higher level language.

Actually I am not interested in any internal kernel stuff.
I just like to tell udev:
"When a USB device with ID 0x1a2b:0x3c4d appears
and when it is not already configured,
then run my setup program and if my setup program
exits successfully, remember the device and that
it is already configured (even after a reboot)."

Of course it cannot work when only "my setup program"
remembers which devices it has already configured
because the user might have used another setup program
before (or did the setup manually). Therefore the
information whether or not it is already configured
must be kept at a unique central place.

Of course this requires persistent storage to keep
the device state even after a reboot and I just need
this for a well working plug-and-play user experience
but I guess the kernel people do not want to do this
for whatever internal kernel reason but again I am
actually not interested in any internal kernel stuff.
Here I am an end-user and I just want to have it work.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Am Donnerstag, 24. April 2008 schrieb Julien BLACHE:
> Johannes Meixner <jsmeix@suse.de> wrote:
>
> Hi,
>
> >> > Be careful with the labels you use. Always use a unique label name, or
> >> > you're asking for troubles. (been there, done that, accidentally
> >> > rendered a number of systems unbootable due to that ...)
> >
> > Many thanks for this enlightening info!
> > Impressive: A thoroughly thought out fail-safe design!
>
> udev is an incredible piece of crap, but the good news is that this
> piece of crap is mostly stable those days. Which is a big step forward
> already.
>
> (and I'll refrain from saying anything at all about the genius who
> invented udev. I'll just mention that he's also the author of "stable
> API is a nonsense".)
>
> > I can only guess that what udev actually does is to
> > concatenate all udev rules files into one single set
> > of rules and then it is not surprising when arbitrary
> > nonsense happens depending on which individual udev rules
> > files exist on a particular system which depends on which
> > individual software packages are installed on this system.
>
> You got it.
>
> > Very nice to debug!
>
> deWHAT?
>
> >> I tried that before after I saw the z60_libsane.rules
> >>
> >> ACTION!="add", GOTO="post_lamp_off"
> >> SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
> >> GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
> >> ENV{lamp_off}="yes"
> >> LABEL="post_lamp_off"
> >>
> >> But given the events, it is obvious not surprising that this is not
> >> working.
> >>
> >> Is anybody aware of a more elegant solution for this problem?
>
> You need to copy a bit more than that from. See the top of the file,
> there's more to it than that, also the way to identify a USB device
> event changed starting with 2.6.22 and the rules are
> backward-compatible in this respect too.
>
> > You cannot have "udev" and "elegant" at the same time
>
> Actually, you can, but you need a bit of udev/uevent knowledge and
> some time on your hands.
>
> > and you cannot have "HAL" and "elegant" at the same time.
>
> It's all HALegant, pff.
>
>
> Welcome to udev-land, Johannes!
>

The script works now reasonably robust (for now) when I plug the USB scanner.
My problem is though, that the script does not get called when I boot the
system and the scanner is plugged already during bootup. Why is this?

I call the script using

blackbox:~# cat /etc/udev/rules.d/z_local.rules
ACTION=="add", SYSFS{idVendor}=="1606", SYSFS{idProduct}=="0010", MODE="0664",
GROUP="scanner", NAME="umax%n", RUN+="/usr/local/bin/umax1220u start",
ENV{lamp_off}="yes"
blackbox:~#

/etc/init.d/udev restart does not call the script either.

Any ideas what I am missing are welcome...

Thanks,
Rainer

--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Rainer Dorsch <rdorsch@web.de> wrote:

Hi,

> The script works now reasonably robust (for now) when I plug the USB scanner.
> My problem is though, that the script does not get called when I boot the
> system and the scanner is plugged already during bootup. Why is this?

Chances are the coldplugging happens from the initrd and your script
isn't available in the initrd. So check that.

Otherwise, I see no reason why the script would not be executed.

JB.

--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Am Samstag, 26. April 2008 schrieb Julien BLACHE:
> Rainer Dorsch <rdorsch@web.de> wrote:
>
> Hi,
>
> > The script works now reasonably robust (for now) when I plug the USB
> > scanner. My problem is though, that the script does not get called whenI
> > boot the system and the scanner is plugged already during bootup. Why is
> > this?
>
> Chances are the coldplugging happens from the initrd and your script
> isn't available in the initrd. So check that.

How would I check if coldplugging happens from the initrd?

And would that explain that /etc/init.d/udev restart no effect?

Thanks,
Rainer

--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Rainer Dorsch <rdorsch@web.de> wrote:

Hi,

>> Chances are the coldplugging happens from the initrd and your script
>> isn't available in the initrd. So check that.
>
> How would I check if coldplugging happens from the initrd?

Well anyway it should be redone once the root FS is mounted and the
/dev/tmpfs is mounted, so it's not an issue.

> And would that explain that /etc/init.d/udev restart no effect?

Nope, that should always work, provided the effect of the udev restart
hasn't changed while I wasn't looking

JB.

--
Julien BLACHE <http://www.jblache.org>
<jb@jblache.org> GPG KeyID 0xF5D65169


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Apr 23, 2008 at 10:53:48PM +0200, Rainer Dorsch wrote:
> Am Mittwoch, 23. April 2008 schrieb Julien BLACHE:
> > Johannes Meixner <jsmeix@suse.de> wrote:
> >
> > Hi,
> >
> > >> umax1220u scripts are started in a sequence (i.e. not in parallel, when
> > >> one is completed the next one starts).
> >
> > When troubleshooting udev rules, use udevmonitor to actually see
> > what's happening in terms of udev events and their properties.
> >
>
> That was a very good hint, thanks. A single scanimage -L causes these events:
>
> UEVENT[1208979136.171525] remove /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UEVENT[1208979136.171696] remove /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UEVENT[1208979136.171702] remove /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)
> UEVENT[1208979136.171707] add /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UEVENT[1208979136.171712] add /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UEVENT[1208979136.171717] add /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)
> UDEV [1208979136.172276] remove /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UDEV [1208979136.172803] remove /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UDEV [1208979136.173239] remove /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)
> UDEV [1208979136.174020] add /class/usb_endpoint/usbdev1.5_ep01
> (usb_endpoint)
> UDEV [1208979136.174831] add /class/usb_endpoint/usbdev1.5_ep82
> (usb_endpoint)
> UDEV [1208979136.175619] add /class/usb_endpoint/usbdev1.5_ep83
> (usb_endpoint)

Our device's udev rules file uses:

#####################################
#####################################
BUS!="usb", ACTION!="add", GOTO="xpp_usb_add_end"
KERNEL=="*_ep*", GOTO="xpp_usb_add_end"
KERNEL=="[0-9]*", GOTO="xpp_usb_add_end"

# the actual rules go in here

LABEL="xpp_usb_add_end"
#####################################
#####################################

>
> >
> > > ACTION!="add", GOTO="end"
> > > SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", RUN+="..."
> > > LABEL="end"

BTW: any idea when is Debian going to move from SYSFS to ATTR ?

My Lenny box does not seem to support ATTR right now.

--
Tzafrir Cohen | tzafrir@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tzafrir@cohens.org.il | | best
ICQ# 16849754 | | friend


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org