| « Entry for January 13, 2008 | International Bowl 2008 » |
Hal info.callouts.add not working
01/07/08
I spent some very frustrating time today trying to an info.callout.add script to run when we added a new USB peripheral to our Centos 5 system. Everything seemed to be OK but the script just wouldn't run. After much head scratching and Google searching I found a clue in a posting on nabble.com entitled Problems getting callouts to work from someone who said their script didn't work when they used an absolute path. Then I found the following on HAL 0.5.10 Specification
"All callouts are searched for and execute in a minimal environment. In addition, the UDI of the device object is exported in the environment variable UDI. All properties of the device object are exported in the environment prefixed with HAL_PROP_. If a device is added or removed is exported in the environment variable HALD_ACTION . The search path for the callout includes the following paths:
$libexecdir(typically/usr/libexec(e.g. Red Hat) or/usr/lib/hal(e.g. Debian))$libdir/hal/scripts(typically/usr/lib/hal/scriptsor/usr/lib64/hal/scripts)$bindir/(typically/usr/bin)
including $PATH the HAL daemon was started with during system initialization. Depending on the distribution, this typically includes /sbin, /usr/sbin, /bin, /usr/sbin. If the program to run is not found in any of these paths, the it will not run even if the given path is absolute. To be portable across operating systems, third party packages providing callouts must therefore only use $libdir/hal/scripts."
I also found the infor at Cliff Hacks Things blog to be useful both for his discussion on getting wifi to work with HAL and Network Manager interactions. Note that the script run by his info.callouts.add has a different path yet again.
I don't have a problem with restricting where scripts can be placed but would have it killed them to log an error message when it couldn't execute the script? Failing silently is not the linux standard, succeeding silently is and whining on failure is.
All this effort was in aid of being able to access a USB device that I physically plugged in. Why O why would the default access for a USB device I have complete physical control over not include write access? It's right up there with not letting me eject the DVD I put in the drive.
No feedback yet
