If HAL is started when /var/cache/hald is not present, it will die like so: [dodo:root]~> hald --daemon=no Runner started - allowed paths are '/usr/libexec:/usr/lib64/hal/scripts:/usr/bin' ** (process:14320): WARNING **: Failed to initialize inotify: Function not implemented Run started hald-generate-fdi-cache (60000) (0) ! full path is '/usr/libexec/hald-generate-fdi-cache', program_dir is '/usr/libexec' 07:03:06.997 [E] create_cache.c:638: Unable to open fdi cache '/var/cache/hald/fdi-cache~' file for writing: No such file or directory 07:03:06.997 [E] create_cache.c:707: Error generating fdi cache pid 14322: rc=1 signaled=0: /usr/libexec/hald-generate-fdi-cache Error binding udev_event socket: Address already in use That originally came from bug #268375 which was fixed by changing the keepdir line. However, in the case of /var/cache being cleaned on reboot(FHS allows this, see [1]), hald will still fail because neither hald nor the init script make sure that /var/cache exists and is a directory before writing cache files. Either HAL upstream needs to fix their behaviour regarding this case or we need to make sure in the init script that /var/cache/hald is present before spawning hald.
(Gentoofan23, do please assign the bug appropriately if you can, it'll just save the wranglers a bit of time...) 5:)
sys-apps/hal was removed from tree wrt #313389, closing as OBSOLETE
