Problems using scsi_id with udevstart

Problems using scsi_id with udevstart

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

Hi,

I added the following udev rule to make human-readable device file names
for my SCSI disks:

BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="scsi_disks/%c-%b",
SYMLINK="%k"

When I run udevstart, I get the following errors in the logfile:

Oct  5 17:25:17 natasha udevstart: PROGRAM execution of 'scsi_id' failed
Oct  5 17:25:17 natasha udevstart: creating device node '/dev/sdy2'
Oct  5 17:25:17 natasha udevstart: PROGRAM execution of 'scsi_id' failed
Oct  5 17:25:17 natasha udevstart: creating device node '/dev/sdz'

scsi_id is failing because no parameters are being passed to it, and I
think DEVPATH is also not being set appropriately.  Here is debug
output:

get_sysfs_device: device 2:0:0:0 is registered with bus 'scsi'
namedev_name_device: sysfs_device-
>path='/sys/devices/pci0000:20/0000:20:01.0/host2/2:0:0:0'
namedev_name_device: sysfs_device->bus_id='2:0:0:0'
namedev_name_device: sysfs_device->bus='scsi'
wait_for_device_to_initialize: looking for file 'vendor' on bus 'scsi'
namedev_name_device: class_dev->name = 'sda'
namedev_name_device: udev->kernel_name = 'sda'
namedev_name_device: kernel_number=''
namedev_name_device: process rule
match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi'
match_rule: BUS matches
match_rule: check PROGRAM
execute_program: 

execute_program: result len 256 too short
execute_program: result is ' matching

Note: no args passed to scsi_id here.

I can get around this by writing a script the passes the appropriate -s
parameter to scsi_id, but I would hope that this sort of thing would
just work.  Is this sort of thing supposed to work with udevstart?  Note
that the Debian udev start-scripts run udevstart at boot.

Some configuration details.

Arch: IA-64
OS: Debian unstable
Udev version: 032
scsi_id version: 0.5

Andrew

-- 
Andrew Patterson                
Hewlett-Packard

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems using scsi_id with udevstart

[Patrick Mansfield]

I don't know much about how udevstart operates. Anyway ...

On Tue, Oct 05, 2004 at 05:33:46PM -0600, Andrew Patterson wrote:
> Hi,
> 
> I added the following udev rule to make human-readable device file names
> for my SCSI disks:
> 
> BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="scsi_disks/%c-%b",
> SYMLINK="%k"

Interesting ... I was thinking of the opposite type of rule to match some
of the SUSE device naming, like:

BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="%k" SYMLINK="scsi_disks/%c-%b", 

> When I run udevstart, I get the following errors in the logfile:
> 
> Oct  5 17:25:17 natasha udevstart: PROGRAM execution of 'scsi_id' failed
> Oct  5 17:25:17 natasha udevstart: creating device node '/dev/sdy2'
> Oct  5 17:25:17 natasha udevstart: PROGRAM execution of 'scsi_id' failed
> Oct  5 17:25:17 natasha udevstart: creating device node '/dev/sdz'
> 
> scsi_id is failing because no parameters are being passed to it, and I
> think DEVPATH is also not being set appropriately.  Here is debug
> output:
> 
> get_sysfs_device: device 2:0:0:0 is registered with bus 'scsi'
> namedev_name_device: sysfs_device-
> >path='/sys/devices/pci0000:20/0000:20:01.0/host2/2:0:0:0'
> namedev_name_device: sysfs_device->bus_id='2:0:0:0'
> namedev_name_device: sysfs_device->bus='scsi'
> wait_for_device_to_initialize: looking for file 'vendor' on bus 'scsi'
> namedev_name_device: class_dev->name = 'sda'
> namedev_name_device: udev->kernel_name = 'sda'
> namedev_name_device: kernel_number=''
> namedev_name_device: process rule
> match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi'
> match_rule: BUS matches
> match_rule: check PROGRAM
> execute_program: 
> 
> execute_program: result len 256 too short
> execute_program: result is ' matching

The above indicates udev thinks the output of scsi_id is too long.

[elm3b79 udev-bk]$ grep NAME_SIZE *.[hc] udev.h | grep define
logging.h:#define LOGNAME_SIZE                  42
udev.h:#define NAME_SIZE                        256
udev.h:#define NAME_SIZE                        256

Greg or Kay, can you verify the above? Should we / can we increase
NAME_SIZE?

Andrew - what does running scsi_id from the command line return for the
device? Like this:
	
	scsi_id -s /block/sdN

-- Patrick Mansfield


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Problems using scsi_id with udevstart

[Kay Sievers]

On Tue, Oct 05, 2004 at 05:33:46PM -0600, Andrew Patterson wrote:
> Hi,
> 
> I added the following udev rule to make human-readable device file names
> for my SCSI disks:
> 
> BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="scsi_disks/%c-%b", SYMLINK="%k"
                                     ^^^^^^^

You need an absolute path here to properly call the binary.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Problems using scsi_id with udevstart

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On Wed, 2004-10-06 at 01:55 +0200, Kay Sievers wrote:
> On Tue, Oct 05, 2004 at 05:33:46PM -0600, Andrew Patterson wrote:
> > Hi,
> > 
> > I added the following udev rule to make human-readable device file names
> > for my SCSI disks:
> > 
> > BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="scsi_disks/%c-%b", SYMLINK="%k"
>                                      ^^^^^^^
> 
> You need an absolute path here to properly call the binary.

Correct, too much cut an pasting.  It still doesn't work even with the
correct path.  Here is the output using /sbin/scsi_id:

namedev_name_device: sysfs_device->bus='scsi'
wait_for_device_to_initialize: looking for file 'vendor' on bus 'scsi'
namedev_name_device: class_dev->name = 'sda'
namedev_name_device: udev->kernel_name = 'sda'
namedev_name_device: kernel_number=''
namedev_name_device: process rule
match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi'
match_rule: BUS matches
match_rule: check for KERNEL dev->kernel='sd*' class_dev->name='sda'
match_rule: KERNEL matches
match_rule: check PROGRAM
execute_program: path = /sbin/scsi_id

execute_program: result is ''
execute_program: exec program status 0x100
match_rule: PROGRAM returned nonzero
match_rule: try parent sysfs device


> Kay
> 

Andrew
-- 
Andrew Patterson                
Hewlett-Packard

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems using scsi_id with udevstart

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

On Tue, 2004-10-05 at 16:53 -0700, Patrick Mansfield wrote:
> I don't know much about how udevstart operates. Anyway ...
> 
> On Tue, Oct 05, 2004 at 05:33:46PM -0600, Andrew Patterson wrote:
> > Hi,
> > 
> > I added the following udev rule to make human-readable device file names
> > for my SCSI disks:
> > 
> > BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="scsi_disks/%c-%b",
> > SYMLINK="%k"
> 
> Interesting ... I was thinking of the opposite type of rule to match some
> of the SUSE device naming, like:
> 
> BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="%k" SYMLINK="scsi_disks/%c-%b", 
> 

Yes, I think this is better as well.  Better to have the real node as
the kernel name and the symlinks to the human-readable stuff.

> > When I run udevstart, I get the following errors in the logfile:
> > 
> > Oct  5 17:25:17 natasha udevstart: PROGRAM execution of 'scsi_id' failed
> > Oct  5 17:25:17 natasha udevstart: creating device node '/dev/sdy2'
> > Oct  5 17:25:17 natasha udevstart: PROGRAM execution of 'scsi_id' failed
> > Oct  5 17:25:17 natasha udevstart: creating device node '/dev/sdz'
> > 
> > scsi_id is failing because no parameters are being passed to it, and I
> > think DEVPATH is also not being set appropriately.  Here is debug
> > output:
> > 
> > get_sysfs_device: device 2:0:0:0 is registered with bus 'scsi'
> > namedev_name_device: sysfs_device-
> > >path='/sys/devices/pci0000:20/0000:20:01.0/host2/2:0:0:0'
> > namedev_name_device: sysfs_device->bus_id='2:0:0:0'
> > namedev_name_device: sysfs_device->bus='scsi'
> > wait_for_device_to_initialize: looking for file 'vendor' on bus 'scsi'
> > namedev_name_device: class_dev->name = 'sda'
> > namedev_name_device: udev->kernel_name = 'sda'
> > namedev_name_device: kernel_number=''
> > namedev_name_device: process rule
> > match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi'
> > match_rule: BUS matches
> > match_rule: check PROGRAM
> > execute_program: 
> > 
> > execute_program: result len 256 too short
> > execute_program: result is ' matching
> 

As Kay mentioned, I need the full path to scsi_id.  When using the full
path you get the following:

match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi'
match_rule: BUS matches
match_rule: check for KERNEL dev->kernel='sd*' class_dev->name='sda'
match_rule: KERNEL matches
match_rule: check PROGRAM
execute_program: path = /sbin/scsi_id

execute_program: result is ''
execute_program: exec program status 0x100
match_rule: PROGRAM returned nonzero
match_rule: try parent sysfs device


Note: here is the error you get when scsi_id is run without any
parameters:

# /sbin/scsi_id
-s must be specified


> The above indicates udev thinks the output of scsi_id is too long.
> 
> [elm3b79 udev-bk]$ grep NAME_SIZE *.[hc] udev.h | grep define
> logging.h:#define LOGNAME_SIZE                  42
> udev.h:#define NAME_SIZE                        256
> udev.h:#define NAME_SIZE                        256
> 
> Greg or Kay, can you verify the above? Should we / can we increase
> NAME_SIZE?
> 
> Andrew - what does running scsi_id from the command line return for the
> device? Like this:
> 	
> 	scsi_id -s /block/sdN
> 

# /sbin/scsi_id -s  /block/sda
2000c50fffe33f611

I have -g set in /etc/scsi_id.conf

Andrew

> -- Patrick Mansfield
> 
-- 
Andrew Patterson                
Hewlett-Packard

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems using scsi_id with udevstart

[Kay Sievers]

On Wed, Oct 06, 2004 at 10:20:56AM -0600, Andrew Patterson wrote:
> On Wed, 2004-10-06 at 01:55 +0200, Kay Sievers wrote:
> > On Tue, Oct 05, 2004 at 05:33:46PM -0600, Andrew Patterson wrote:
> > > Hi,
> > > 
> > > I added the following udev rule to make human-readable device file names
> > > for my SCSI disks:
> > > 
> > > BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="scsi_disks/%c-%b", SYMLINK="%k"
> >                                      ^^^^^^^
> > 
> > You need an absolute path here to properly call the binary.
> 
> Correct, too much cut an pasting.  It still doesn't work even with the
> correct path.  Here is the output using /sbin/scsi_id:
> 
> namedev_name_device: sysfs_device->bus='scsi'
> wait_for_device_to_initialize: looking for file 'vendor' on bus 'scsi'
> namedev_name_device: class_dev->name = 'sda'
> namedev_name_device: udev->kernel_name = 'sda'
> namedev_name_device: kernel_number=''
> namedev_name_device: process rule
> match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi'
> match_rule: BUS matches
> match_rule: check for KERNEL dev->kernel='sd*' class_dev->name='sda'
> match_rule: KERNEL matches
> match_rule: check PROGRAM
> execute_program: path = /sbin/scsi_id
> 
> execute_program: result is ''
> execute_program: exec program status 0x100
> match_rule: PROGRAM returned nonzero
> match_rule: try parent sysfs device

Where is the "path = /sbin/scsi_id" line coming from? Other lines are missing.
Did you change anything in the code. It should look more like this:

  udev[25565]: match_rule: KERNEL matches
  udev[25565]: match_rule: check PROGRAM
  udev[25565]: execute_program: execute '/bin/false' with main argument
  udev[25565]: execute_program: result is ''
  udev[25565]: execute_program: exec program status 0x100
  udev[25565]: match_rule: PROGRAM returned nonzero
  udev[25565]: match_rule: try parent sysfs device

And please try to run scsi_id on the commandline if it works there.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Problems using scsi_id with udevstart

[Patrick Mansfield]

On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:

> Note: here is the error you get when scsi_id is run without any
> parameters:
> 
> # /sbin/scsi_id
> -s must be specified

For the udev PROGRAM rules with no arguments, it is effectively invoked
like this (well there are other environment values but scsi_id only cares
about DEVPATH):

DEVPATH=/block/sda /sbin/scsi_id block

Since udev does not have a % whatever for the DEVPATH, you can't pass it
in the rule file, that is this rule would not work for anything but sda:

	PROGRAM="/sbin/scsi_id -s /block/sda"

You would need a new udev %-something, like:

	PROGRAM="/sbin/scsi_id -s %p"

-- Patrick Mansfield


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Problems using scsi_id with udevstart

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]

On Wed, 2004-10-06 at 18:44 +0200, Kay Sievers wrote:
> On Wed, Oct 06, 2004 at 10:20:56AM -0600, Andrew Patterson wrote:
> > On Wed, 2004-10-06 at 01:55 +0200, Kay Sievers wrote:
> > > On Tue, Oct 05, 2004 at 05:33:46PM -0600, Andrew Patterson wrote:
> > > > Hi,
> > > > 
> > > > I added the following udev rule to make human-readable device file names
> > > > for my SCSI disks:
> > > > 
> > > > BUS="scsi", KERNEL="sd*", PROGRAM="scsi_id", NAME="scsi_disks/%c-%b", SYMLINK="%k"
> > >                                      ^^^^^^^
> > > 
> > > You need an absolute path here to properly call the binary.
> > 
> > Correct, too much cut an pasting.  It still doesn't work even with the
> > correct path.  Here is the output using /sbin/scsi_id:
> > 
> > namedev_name_device: sysfs_device->bus='scsi'
> > wait_for_device_to_initialize: looking for file 'vendor' on bus 'scsi'
> > namedev_name_device: class_dev->name = 'sda'
> > namedev_name_device: udev->kernel_name = 'sda'
> > namedev_name_device: kernel_number=''
> > namedev_name_device: process rule
> > match_rule: check for BUS dev->bus='scsi' sysfs_device->bus='scsi'
> > match_rule: BUS matches
> > match_rule: check for KERNEL dev->kernel='sd*' class_dev->name='sda'
> > match_rule: KERNEL matches
> > match_rule: check PROGRAM
> > execute_program: path = /sbin/scsi_id
> > 
> > execute_program: result is ''
> > execute_program: exec program status 0x100
> > match_rule: PROGRAM returned nonzero
> > match_rule: try parent sysfs device
> 
> Where is the "path = /sbin/scsi_id" line coming from? Other lines are missing.
> Did you change anything in the code. It should look more like this:
> 

Yep, added some debugging code.  Here are the diff's:

diff -Nur udev-032/namedev.c udev-032.new/namedev.c
--- udev-032/namedev.c  2004-09-13 23:55:36.000000000 -0600
+++ udev-032.new/namedev.c      2004-10-05 17:09:08.000000000 -0600
@@ -423,6 +423,8 @@
        char arg[PROGRAM_SIZE];
        char *argv[sizeof(arg) / 2];
        int i;
+
+       dbg("path = %s\n", path);

        i = 0;
        if (strchr(path, ' ')) {
diff -Nur udev-032/udev.c udev-032.new/udev.c
--- udev-032/udev.c     2004-09-13 23:55:32.000000000 -0600
+++ udev-032.new/udev.c 2004-10-05 16:58:37.000000000 -0600
@@ -50,8 +50,10 @@
                return;

        va_start(args, format);
-       vsyslog(level, format, args);
+//     vsyslog(level, format, args);
+       vprintf(format, args);
        va_end(args);
+       printf("\n");
 }
 #endif


Here is the compile line I used:

$ make  USE_LOG=true DEBUG=true

>   udev[25565]: match_rule: KERNEL matches
>   udev[25565]: match_rule: check PROGRAM
>   udev[25565]: execute_program: execute '/bin/false' with main argument
>   udev[25565]: execute_program: result is ''
>   udev[25565]: execute_program: exec program status 0x100
>   udev[25565]: match_rule: PROGRAM returned nonzero
>   udev[25565]: match_rule: try parent sysfs device
> 
> And please try to run scsi_id on the commandline if it works there.
> 

# /sbin/scsi_id 
-s must be specified

# /sbin/scsi_id -s /block/sda
2000c50fffe33f611

The -g option was added in /etc/scsi_id.cong

> Kay
> 

Andrew

-- 
Andrew Patterson                
Hewlett-Packard

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems using scsi_id with udevstart

[Kay Sievers]

On Wed, Oct 06, 2004 at 11:33:55AM -0600, Andrew Patterson wrote:
> On Wed, 2004-10-06 at 18:44 +0200, Kay Sievers wrote:
> > 
> > Where is the "path = /sbin/scsi_id" line coming from? Other lines are missing.
> > Did you change anything in the code. It should look more like this:
> > 
> 
> Yep, added some debugging code.  Here are the diff's:

Ok, I've no idea :) Could you please try:

  DEVPATH=/block/sda ACTION­d strace -o /tmp/udev-callout-trace -f -s1000 /sbin/udev block

It will create a ~2MB file in /tmp with something like this:

  26863 rt_sigaction(SIGPIPE, {0x2ab9a0, [], SA_RESTORER, 0x212718}, {SIG_DFL}, 8) = 0¶
  26863 send(3, "<15>Oct  6 19:52:27 udev: execute_program: execute \'/sbin/scsi_id\' with main argument", 85, 0) = 85¶
  26863 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0¶
  26863 execve("/sbin/scsi_id", ["/sbin/udev", "block"], [/* 26 vars */]) = 0¶
  26863 uname({sys="Linux", node="pim", ...}) = 0¶
  26863 brk(0)                            = 0x9f0e000¶
  ...

This should give us some more information.
Please send it to me by privat email.

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Problems using scsi_id with udevstart

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> 
> > Note: here is the error you get when scsi_id is run without any
> > parameters:
> > 
> > # /sbin/scsi_id
> > -s must be specified
> 
> For the udev PROGRAM rules with no arguments, it is effectively invoked
> like this (well there are other environment values but scsi_id only cares
> about DEVPATH):
> 
> DEVPATH=/block/sda /sbin/scsi_id block
> 

This is what I thought was supposed to happen.  I printed out the
arguments and the environment when scsi_id was invoked through
udevstart.  No arguments were passed and UDEVPATH was always set
to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
be set correctly.

Example:

DEVNAME=/dev/sda
DEVPATH=/class/net/lo

> Since udev does not have a % whatever for the DEVPATH, you can't pass it
> in the rule file, that is this rule would not work for anything but sda:
> 
> 	PROGRAM="/sbin/scsi_id -s /block/sda"
> 
> You would need a new udev %-something, like:
> 
> 	PROGRAM="/sbin/scsi_id -s %p"

Yeah, I was hoping for something like the %p.  Seems like it would be
nice to have one in any case.  However, I think udevstart should just
work like using plain /sbin/scsi_id.  That way, you don't have to have a
separate rules for udev and udevstart (if this is even possible).

I am still not sure if I am running into a bug, or that I just don't
understand how udevstart is supposed to work.  My goal is to be able to
just plug in arbitrary SCSI devices and not have to worry about human-
readable device files being created.  From the sample scripts I have
seen, the current method is to plug in your device, then run some script
(like gen_scsi_id_udev_rules.sh that comes with scsi_id) that generates
udev rules for you, which you must then hand add to the udev rulesets.
If udevstart worked like I hoped it would, you could just
edit /etc/scsi_id.conf to account for bad devices that need special
handling.

Andrew

> 
> -- Patrick Mansfield
> 
-- 
Andrew Patterson                
Hewlett-Packard

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems using scsi_id with udevstart

[Kay Sievers]

On Wed, 2004-10-06 at 12:42 -0600, Andrew Patterson wrote:
> On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> > On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> > 
> > > Note: here is the error you get when scsi_id is run without any
> > > parameters:
> > > 
> > > # /sbin/scsi_id
> > > -s must be specified
> > 
> > For the udev PROGRAM rules with no arguments, it is effectively invoked
> > like this (well there are other environment values but scsi_id only cares
> > about DEVPATH):
> > 
> > DEVPATH=/block/sda /sbin/scsi_id block
> > 
> 
> This is what I thought was supposed to happen.  I printed out the
> arguments and the environment when scsi_id was invoked through
> udevstart.  No arguments were passed and UDEVPATH was always set
> to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
> be set correctly.

Yes, this is a bug. We need to export the DEVPATH for the callout if we
run as udevstart. I will fix that now.

Thanks,
Kay



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Problems using scsi_id with udevstart

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

On Wed, 2004-10-06 at 21:13 +0200, Kay Sievers wrote:
> On Wed, 2004-10-06 at 12:42 -0600, Andrew Patterson wrote:
> > On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> > > On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> > > 
> > > > Note: here is the error you get when scsi_id is run without any
> > > > parameters:
> > > > 
> > > > # /sbin/scsi_id
> > > > -s must be specified
> > > 
> > > For the udev PROGRAM rules with no arguments, it is effectively invoked
> > > like this (well there are other environment values but scsi_id only cares
> > > about DEVPATH):
> > > 
> > > DEVPATH=/block/sda /sbin/scsi_id block
> > > 
> > 
> > This is what I thought was supposed to happen.  I printed out the
> > arguments and the environment when scsi_id was invoked through
> > udevstart.  No arguments were passed and UDEVPATH was always set
> > to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
> > be set correctly.
> 
> Yes, this is a bug. We need to export the DEVPATH for the callout if we
> run as udevstart. I will fix that now.

So did you confirm that the subsystem is indeed being passed as an
argument when running udevstart as well?  My testing shows no.  I think
you need both to make this work.

Andrew

> 
> Thanks,
> Kay
> 
-- 
Andrew Patterson                
Hewlett-Packard

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems using scsi_id with udevstart

[Kay Sievers]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Wed, Oct 06, 2004 at 03:22:03PM -0600, Andrew Patterson wrote:
> On Wed, 2004-10-06 at 21:13 +0200, Kay Sievers wrote:
> > On Wed, 2004-10-06 at 12:42 -0600, Andrew Patterson wrote:
> > > On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> > > > On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> > > > 
> > > > > Note: here is the error you get when scsi_id is run without any
> > > > > parameters:
> > > > > 
> > > > > # /sbin/scsi_id
> > > > > -s must be specified
> > > > 
> > > > For the udev PROGRAM rules with no arguments, it is effectively invoked
> > > > like this (well there are other environment values but scsi_id only cares
> > > > about DEVPATH):
> > > > 
> > > > DEVPATH=/block/sda /sbin/scsi_id block
> > > > 
> > > 
> > > This is what I thought was supposed to happen.  I printed out the
> > > arguments and the environment when scsi_id was invoked through
> > > udevstart.  No arguments were passed and UDEVPATH was always set
> > > to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
> > > be set correctly.
> > 
> > Yes, this is a bug. We need to export the DEVPATH for the callout if we
> > run as udevstart. I will fix that now.
> 
> So did you confirm that the subsystem is indeed being passed as an
> argument when running udevstart as well?  My testing shows no.  I think
> you need both to make this work.

Yes, when udevstart was running we didn't set the environment and the
subsystem argument for the callouts the dev.d/ scripts.

Here is a fix, that sets that with every udevstart iteration, corrects
argv[0] to be the basename() only not the whole path  and adds a test
for invoking callouts without arguments.

Thanks,
Kay

[-- Attachment #2: udevstart-env-fix-01.patch --]
[-- Type: text/plain, Size: 3990 bytes --]

===== namedev.c 1.147 vs edited =====
--- 1.147/namedev.c	2004-09-20 16:01:58 +02:00
+++ edited/namedev.c	2004-10-06 23:27:35 +02:00
@@ -412,7 +412,7 @@ static void fix_kernel_name(struct udevi
 	}
 }
 
-static int execute_program(char *path, char *value, int len)
+static int execute_program(const char *path, char *value, int len)
 {
 	int retval;
 	int count;
@@ -421,12 +421,12 @@ static int execute_program(char *path, c
 	pid_t pid;
 	char *pos;
 	char arg[PROGRAM_SIZE];
-	char *argv[sizeof(arg) / 2];
+	char *argv[(PROGRAM_SIZE / 2) + 1];
 	int i;
 
+	strfieldcpy(arg, path);
 	i = 0;
 	if (strchr(path, ' ')) {
-		strfieldcpy(arg, path);
 		pos = arg;
 		while (pos != NULL) {
 			if (pos[0] == '\'') {
@@ -441,8 +441,19 @@ static int execute_program(char *path, c
 			dbg("arg[%i] '%s'", i, argv[i]);
 			i++;
 		}
+		argv[i] =  NULL;
+		dbg("execute '%s' with parsed arguments", arg);
+	} else {
+		argv[0] = arg;
+		argv[1] = main_argv[1];
+		argv[2] = NULL;
+		dbg("execute '%s' with subsystem '%s' argument", arg, argv[1]);
 	}
-	argv[i] =  NULL;
+
+	/* set basename() only */
+	pos = strrchr(argv[0], '/');
+	if (pos != NULL)
+		argv[0] = &pos[1];
 
 	retval = pipe(fds);
 	if (retval != 0) {
@@ -456,13 +467,7 @@ static int execute_program(char *path, c
 		/* child */
 		/* dup2 write side of pipe to STDOUT */
 		dup2(fds[1], STDOUT_FILENO);
-		if (argv[0] !=  NULL) {
-			dbg("execute '%s' with given arguments", argv[0]);
-			retval = execv(argv[0], argv);
-		} else {
-			dbg("execute '%s' with main argument", path);
-			retval = execv(path, main_argv);
-		}
+		retval = execv(arg, argv);
 
 		info(FIELD_PROGRAM " execution of '%s' failed", path);
 		exit(1);
===== udevstart.c 1.17 vs edited =====
--- 1.17/udevstart.c	2004-09-14 15:13:59 +02:00
+++ edited/udevstart.c	2004-10-06 22:43:28 +02:00
@@ -86,6 +86,21 @@ static char *first_list[] = {
 	NULL,
 };
 
+static void add_device(char *path, char *subsys, int fake)
+{
+	char *argv[3];
+
+	/* fake argument vector and environment for callouts and dev.d/ */
+	argv[0] = "udev";
+	argv[1] = subsys;
+	argv[2] = NULL;
+
+	main_argv = argv;
+	setenv("DEVPATH", path, 1);
+	setenv("ACTION", "add", 1);
+	udev_add_device(path, subsys, fake);
+}
+
 static void exec_list(struct list_head *device_list)
 {
 	struct device *loop_device;
@@ -96,7 +111,7 @@ static void exec_list(struct list_head *
 	list_for_each_entry_safe(loop_device, tmp_device, device_list, list) {
 		for (i=0; first_list[i] != NULL; i++) {
 			if (strncmp(loop_device->path, first_list[i], strlen(first_list[i])) == 0) {
-				udev_add_device(loop_device->path, loop_device->subsys, NOFAKE);
+				add_device(loop_device->path, loop_device->subsys, NOFAKE);
 				list_del(&loop_device->list);
 				free(loop_device);
 				break;
@@ -116,14 +131,14 @@ static void exec_list(struct list_head *
 		if (found)
 			continue;
 
-		udev_add_device(loop_device->path, loop_device->subsys, NOFAKE);
+		add_device(loop_device->path, loop_device->subsys, NOFAKE);
 		list_del(&loop_device->list);
 		free(loop_device);
 	}
 
 	/* handle the rest of the devices left over, if any */
 	list_for_each_entry_safe(loop_device, tmp_device, device_list, list) {
-		udev_add_device(loop_device->path, loop_device->subsys, NOFAKE);
+		add_device(loop_device->path, loop_device->subsys, NOFAKE);
 		list_del(&loop_device->list);
 		free(loop_device);
 	}
===== test/udev-test.pl 1.58 vs edited =====
--- 1.58/test/udev-test.pl	2004-09-14 19:42:53 +02:00
+++ edited/test/udev-test.pl	2004-10-06 23:11:09 +02:00
@@ -256,6 +256,15 @@ BUS="scsi", PROGRAM="/bin/echo -n specia
 EOF
 	},
 	{
+		desc		=> "program result substitution (no argument should be subsystem)",
+		subsys		=> "block",
+		devpath		=> "/block/sda/sda3",
+		exp_name	=> "subsys_block" ,
+		conf		=> <<EOF
+BUS="scsi", PROGRAM="/bin/echo", RESULT="block", NAME="subsys_block"
+EOF
+	},
+	{
 		desc		=> "program result substitution (newline removal)",
 		subsys		=> "block",
 		devpath		=> "/block/sda/sda3",

Re: Problems using scsi_id with udevstart

[Greg KH]

On Wed, Oct 06, 2004 at 11:39:17PM +0200, Kay Sievers wrote:
> On Wed, Oct 06, 2004 at 03:22:03PM -0600, Andrew Patterson wrote:
> > On Wed, 2004-10-06 at 21:13 +0200, Kay Sievers wrote:
> > > On Wed, 2004-10-06 at 12:42 -0600, Andrew Patterson wrote:
> > > > On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> > > > > On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> > > > > 
> > > > > > Note: here is the error you get when scsi_id is run without any
> > > > > > parameters:
> > > > > > 
> > > > > > # /sbin/scsi_id
> > > > > > -s must be specified
> > > > > 
> > > > > For the udev PROGRAM rules with no arguments, it is effectively invoked
> > > > > like this (well there are other environment values but scsi_id only cares
> > > > > about DEVPATH):
> > > > > 
> > > > > DEVPATH=/block/sda /sbin/scsi_id block
> > > > > 
> > > > 
> > > > This is what I thought was supposed to happen.  I printed out the
> > > > arguments and the environment when scsi_id was invoked through
> > > > udevstart.  No arguments were passed and UDEVPATH was always set
> > > > to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
> > > > be set correctly.
> > > 
> > > Yes, this is a bug. We need to export the DEVPATH for the callout if we
> > > run as udevstart. I will fix that now.
> > 
> > So did you confirm that the subsystem is indeed being passed as an
> > argument when running udevstart as well?  My testing shows no.  I think
> > you need both to make this work.
> 
> Yes, when udevstart was running we didn't set the environment and the
> subsystem argument for the callouts the dev.d/ scripts.
> 
> Here is a fix, that sets that with every udevstart iteration, corrects
> argv[0] to be the basename() only not the whole path  and adds a test
> for invoking callouts without arguments.

Applied, thanks.

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Problems using scsi_id with udevstart

[Andrew Patterson]

[-- Attachment #1: Type: text/plain, Size: 6379 bytes --]

On Wed, 2004-10-06 at 23:39 +0200, Kay Sievers wrote:
> On Wed, Oct 06, 2004 at 03:22:03PM -0600, Andrew Patterson wrote:
> > On Wed, 2004-10-06 at 21:13 +0200, Kay Sievers wrote:
> > > On Wed, 2004-10-06 at 12:42 -0600, Andrew Patterson wrote:
> > > > On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> > > > > On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> > > > > 
> > > > > > Note: here is the error you get when scsi_id is run without any
> > > > > > parameters:
> > > > > > 
> > > > > > # /sbin/scsi_id
> > > > > > -s must be specified
> > > > > 
> > > > > For the udev PROGRAM rules with no arguments, it is effectively invoked
> > > > > like this (well there are other environment values but scsi_id only cares
> > > > > about DEVPATH):
> > > > > 
> > > > > DEVPATH=/block/sda /sbin/scsi_id block
> > > > > 
> > > > 
> > > > This is what I thought was supposed to happen.  I printed out the
> > > > arguments and the environment when scsi_id was invoked through
> > > > udevstart.  No arguments were passed and UDEVPATH was always set
> > > > to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
> > > > be set correctly.
> > > 
> > > Yes, this is a bug. We need to export the DEVPATH for the callout if we
> > > run as udevstart. I will fix that now.
> > 
> > So did you confirm that the subsystem is indeed being passed as an
> > argument when running udevstart as well?  My testing shows no.  I think
> > you need both to make this work.
> 
> Yes, when udevstart was running we didn't set the environment and the
> subsystem argument for the callouts the dev.d/ scripts.
> 
> Here is a fix, that sets that with every udevstart iteration, corrects
> argv[0] to be the basename() only not the whole path  and adds a test
> for invoking callouts without arguments.
> 
> Thanks,
> Kay

This works fine.  Thanks.

Andrew

> Plain text document attachment (udevstart-env-fix-01.patch)
> ===== namedev.c 1.147 vs edited =====
> --- 1.147/namedev.c	2004-09-20 16:01:58 +02:00
> +++ edited/namedev.c	2004-10-06 23:27:35 +02:00
> @@ -412,7 +412,7 @@ static void fix_kernel_name(struct udevi
>  	}
>  }
>  
> -static int execute_program(char *path, char *value, int len)
> +static int execute_program(const char *path, char *value, int len)
>  {
>  	int retval;
>  	int count;
> @@ -421,12 +421,12 @@ static int execute_program(char *path, c
>  	pid_t pid;
>  	char *pos;
>  	char arg[PROGRAM_SIZE];
> -	char *argv[sizeof(arg) / 2];
> +	char *argv[(PROGRAM_SIZE / 2) + 1];
>  	int i;
>  
> +	strfieldcpy(arg, path);
>  	i = 0;
>  	if (strchr(path, ' ')) {
> -		strfieldcpy(arg, path);
>  		pos = arg;
>  		while (pos != NULL) {
>  			if (pos[0] == '\'') {
> @@ -441,8 +441,19 @@ static int execute_program(char *path, c
>  			dbg("arg[%i] '%s'", i, argv[i]);
>  			i++;
>  		}
> +		argv[i] =  NULL;
> +		dbg("execute '%s' with parsed arguments", arg);
> +	} else {
> +		argv[0] = arg;
> +		argv[1] = main_argv[1];
> +		argv[2] = NULL;
> +		dbg("execute '%s' with subsystem '%s' argument", arg, argv[1]);
>  	}
> -	argv[i] =  NULL;
> +
> +	/* set basename() only */
> +	pos = strrchr(argv[0], '/');
> +	if (pos != NULL)
> +		argv[0] = &pos[1];
>  
>  	retval = pipe(fds);
>  	if (retval != 0) {
> @@ -456,13 +467,7 @@ static int execute_program(char *path, c
>  		/* child */
>  		/* dup2 write side of pipe to STDOUT */
>  		dup2(fds[1], STDOUT_FILENO);
> -		if (argv[0] !=  NULL) {
> -			dbg("execute '%s' with given arguments", argv[0]);
> -			retval = execv(argv[0], argv);
> -		} else {
> -			dbg("execute '%s' with main argument", path);
> -			retval = execv(path, main_argv);
> -		}
> +		retval = execv(arg, argv);
>  
>  		info(FIELD_PROGRAM " execution of '%s' failed", path);
>  		exit(1);
> ===== udevstart.c 1.17 vs edited =====
> --- 1.17/udevstart.c	2004-09-14 15:13:59 +02:00
> +++ edited/udevstart.c	2004-10-06 22:43:28 +02:00
> @@ -86,6 +86,21 @@ static char *first_list[] = {
>  	NULL,
>  };
>  
> +static void add_device(char *path, char *subsys, int fake)
> +{
> +	char *argv[3];
> +
> +	/* fake argument vector and environment for callouts and dev.d/ */
> +	argv[0] = "udev";
> +	argv[1] = subsys;
> +	argv[2] = NULL;
> +
> +	main_argv = argv;
> +	setenv("DEVPATH", path, 1);
> +	setenv("ACTION", "add", 1);
> +	udev_add_device(path, subsys, fake);
> +}
> +
>  static void exec_list(struct list_head *device_list)
>  {
>  	struct device *loop_device;
> @@ -96,7 +111,7 @@ static void exec_list(struct list_head *
>  	list_for_each_entry_safe(loop_device, tmp_device, device_list, list) {
>  		for (i=0; first_list[i] != NULL; i++) {
>  			if (strncmp(loop_device->path, first_list[i], strlen(first_list[i])) == 0) {
> -				udev_add_device(loop_device->path, loop_device->subsys, NOFAKE);
> +				add_device(loop_device->path, loop_device->subsys, NOFAKE);
>  				list_del(&loop_device->list);
>  				free(loop_device);
>  				break;
> @@ -116,14 +131,14 @@ static void exec_list(struct list_head *
>  		if (found)
>  			continue;
>  
> -		udev_add_device(loop_device->path, loop_device->subsys, NOFAKE);
> +		add_device(loop_device->path, loop_device->subsys, NOFAKE);
>  		list_del(&loop_device->list);
>  		free(loop_device);
>  	}
>  
>  	/* handle the rest of the devices left over, if any */
>  	list_for_each_entry_safe(loop_device, tmp_device, device_list, list) {
> -		udev_add_device(loop_device->path, loop_device->subsys, NOFAKE);
> +		add_device(loop_device->path, loop_device->subsys, NOFAKE);
>  		list_del(&loop_device->list);
>  		free(loop_device);
>  	}
> ===== test/udev-test.pl 1.58 vs edited =====
> --- 1.58/test/udev-test.pl	2004-09-14 19:42:53 +02:00
> +++ edited/test/udev-test.pl	2004-10-06 23:11:09 +02:00
> @@ -256,6 +256,15 @@ BUS="scsi", PROGRAM="/bin/echo -n specia
>  EOF
>  	},
>  	{
> +		desc		=> "program result substitution (no argument should be subsystem)",
> +		subsys		=> "block",
> +		devpath		=> "/block/sda/sda3",
> +		exp_name	=> "subsys_block" ,
> +		conf		=> <<EOF
> +BUS="scsi", PROGRAM="/bin/echo", RESULT="block", NAME="subsys_block"
> +EOF
> +	},
> +	{
>  		desc		=> "program result substitution (newline removal)",
>  		subsys		=> "block",
>  		devpath		=> "/block/sda/sda3",

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems using scsi_id with udevstart

[Kay Sievers]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

On Wed, Oct 06, 2004 at 03:24:58PM -0700, Greg KH wrote:
> On Wed, Oct 06, 2004 at 11:39:17PM +0200, Kay Sievers wrote:
> > On Wed, Oct 06, 2004 at 03:22:03PM -0600, Andrew Patterson wrote:
> > > On Wed, 2004-10-06 at 21:13 +0200, Kay Sievers wrote:
> > > > On Wed, 2004-10-06 at 12:42 -0600, Andrew Patterson wrote:
> > > > > On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> > > > > > On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> > > > > > 
> > > > > > > Note: here is the error you get when scsi_id is run without any
> > > > > > > parameters:
> > > > > > > 
> > > > > > > # /sbin/scsi_id
> > > > > > > -s must be specified
> > > > > > 
> > > > > > For the udev PROGRAM rules with no arguments, it is effectively invoked
> > > > > > like this (well there are other environment values but scsi_id only cares
> > > > > > about DEVPATH):
> > > > > > 
> > > > > > DEVPATH=/block/sda /sbin/scsi_id block
> > > > > > 
> > > > > 
> > > > > This is what I thought was supposed to happen.  I printed out the
> > > > > arguments and the environment when scsi_id was invoked through
> > > > > udevstart.  No arguments were passed and UDEVPATH was always set
> > > > > to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
> > > > > be set correctly.
> > > > 
> > > > Yes, this is a bug. We need to export the DEVPATH for the callout if we
> > > > run as udevstart. I will fix that now.
> > > 
> > > So did you confirm that the subsystem is indeed being passed as an
> > > argument when running udevstart as well?  My testing shows no.  I think
> > > you need both to make this work.
> > 
> > Yes, when udevstart was running we didn't set the environment and the
> > subsystem argument for the callouts the dev.d/ scripts.
> > 
> > Here is a fix, that sets that with every udevstart iteration, corrects
> > argv[0] to be the basename() only not the whole path  and adds a test
> > for invoking callouts without arguments.
> 
> Applied, thanks.

Here is the correction for the dev.d/ scripts too. We should pass
the right argv[0] here too. A script may depend on the right value, as
udev does with udev/udevstart.

Here is the old version:
  [pid  4692] execve("/etc/dev.d/default/log.dev", ["./udev", "block"], [/* 41 vars */]) = 0

this the new one:
  [pid  9832] execve("/etc/dev.d/default/log.dev", ["/etc/dev.d/default/log.dev", "block"], [/* 41 vars */]) = 0

Thanks,
Kay

[-- Attachment #2: udev-dev.d-argv0-fix-01.patch --]
[-- Type: text/plain, Size: 963 bytes --]

===== dev_d.c 1.10 vs edited =====
--- 1.10/dev_d.c	2004-09-20 16:02:44 +02:00
+++ edited/dev_d.c	2004-10-07 00:57:31 +02:00
@@ -39,6 +39,7 @@ static int run_program(char *name)
 {
 	pid_t pid;
 	int fd;
+	char *argv[3];
 
 	dbg("running %s", name);
 
@@ -54,7 +55,12 @@ static int run_program(char *name)
 			dup2(fd, STDERR_FILENO);
 		}
 		close(fd);
-		execv(name, main_argv);
+
+		argv[0] = name;
+		argv[1] = main_argv[1];
+		argv[2] = NULL;
+
+		execv(name, argv);
 		dbg("exec of child failed");
 		exit(1);
 	case -1:
===== namedev.c 1.148 vs edited =====
--- 1.148/namedev.c	2004-10-06 23:27:35 +02:00
+++ edited/namedev.c	2004-10-07 00:51:40 +02:00
@@ -450,11 +450,6 @@ static int execute_program(const char *p
 		dbg("execute '%s' with subsystem '%s' argument", arg, argv[1]);
 	}
 
-	/* set basename() only */
-	pos = strrchr(argv[0], '/');
-	if (pos != NULL)
-		argv[0] = &pos[1];
-
 	retval = pipe(fds);
 	if (retval != 0) {
 		dbg("pipe failed");

Re: Problems using scsi_id with udevstart

[Greg KH]

On Thu, Oct 07, 2004 at 01:08:04AM +0200, Kay Sievers wrote:
> Here is the correction for the dev.d/ scripts too. We should pass
> the right argv[0] here too. A script may depend on the right value, as
> udev does with udev/udevstart.
> 
> Here is the old version:
>   [pid  4692] execve("/etc/dev.d/default/log.dev", ["./udev", "block"], [/* 41 vars */]) = 0
> 
> this the new one:
>   [pid  9832] execve("/etc/dev.d/default/log.dev", ["/etc/dev.d/default/log.dev", "block"], [/* 41 vars */]) = 0

Applied, thanks.

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel