Bugzilla – Bug 119210
Haldaemon dies and does not start correctly
Last modified: 2005-10-18 00:29:32 UTC
This is coming as a side-result of bug #106897. It seems that at some point, hal is dying and if I notice that it's not running and do an /etc/init.d/ haldaemon stop and start, and then check to see if it's running with "ps waux | grep hal", I don't see any hal processes running. This might be affecting bug #106897 in that powersave depends on hal. I just forced powersave to stop/start and did a suspend/resume on my laptop and I notice that now (after suspend/resume), /etc/init.d/haldaemon start does seem to work: > ps waux | grep hal root 29540 7.4 0.3 4960 3676 ? Ss 08:59 0:00 /usr/sbin/hald --daemon=yes --retain-privileges root 29560 0.0 0.0 1792 612 ? S 08:59 0:00 hald-addon- storage
Please update to the last version of SUSE Linux. Preview 1 is to old to reproduce this here, we had to many changes since this version.
any news? Can I close the bug?
Well, I've updated to 10.0-final, and I have hal-0.5.4-6 installed. I don't know if you want to close this or not, since hald is not running currently, and this is after 12 hours of uptime. Is hald supposed to be running at all times? If it is, then I think there's a bug somewhere that is causing it to crash/die/etc., and I'd like to help figure out why this is happening. How can I debug this? If it's not supposed to be running at all times, and it's acceptable that at some point it stops running, then I guess you can close this bug?
Yes, HAL should always run. I have no idea, why it dies at your machine, we never had such a problem here. Could you restart hal with 'rchal restart' ? - Is there any message in /var/log/message related to hal (try: 'grep hal /var/ log/messages')? - Is there any other hal process ('ps aux | grep hal')? - Is dbus running? - Did you updated all packages from YOU ?
- There are no running hal processes, per "ps waux | grep hal" > grep hal /var/log/messages Oct 8 21:41:16 linux hal-subfs-mount[4521]: MOUNTPOINT:: /media/floppy Oct 8 21:41:16 linux hal-subfs-mount[4521]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=floppyfss,sync,procuid,nosuid,nodev,exec / dev/fd0 "/media/floppy" Oct 8 21:41:16 linux hal-subfs-mount[4807]: SYMLINKS:: disk/by-path/pci-0000: 00:1f.1-ide-1:0 dvd cdrom Oct 8 21:41:16 linux hal-subfs-mount[4807]: MOUNT_POINT:: /media/dvd Oct 8 21:41:16 linux hal-subfs-mount[4807]: MOUNTPOINT:: /media/dvd Oct 8 21:41:16 linux hal-subfs-mount[4807]: Collected mount options and Called(0) /bin/mount -t subfs -o fs=cdfss,ro,procuid,nosuid,nodev,exec, iocharset=utf8 /dev/hdc "/media/dvd" Oct 8 21:42:26 linux hal-subfs-mount[5187]: By hald-subfs-mount created link / media/SU1000_001 got removed. Oct 8 23:11:56 gandalf hal-subfs-mount[13160]: Device: /dev/hdc already mounted, exit now! Oct 9 00:11:17 gandalf hal-subfs-mount[16736]: Device: /dev/hdc already mounted, exit now! Oct 9 00:11:58 gandalf hal-subfs-mount[16747]: Device: /dev/hdc already mounted, exit now! > ps waux | grep dbus 100 3765 0.0 0.1 3520 1544 ? Ss Oct09 0:01 /usr/bin/dbus- daemon --system - after restarting hal with "sudo rchal restart", after I "ps waux | grep hal", it's still not running. This is what I've seen before too--once hald dies, it doesn't seem to be restartable. And yes, I'm fully updated from YOU.
Is there maybe the pidfile of hal /var/run/hal (haldaemon.pid) after the haldaemon died? If so, remove the pid file before restart.
Okay, after having done that.... `--> ps waux | grep hal root 30564 9.7 0.3 5028 3720 ? Ss 15:02 0:01 /usr/sbin/hald --daemon=yes --retain-privileges root 30591 0.0 0.0 1796 612 ? S 15:02 0:00 hald-addon- storage So, it starts up okay after that manual intervention. Shouldn't an extra step be made in the startup script to see if the pid that is in that file is actually valid before not doing anything?
The startup script do this normaly. If the haldaemon died what say 'rchal start'? Is there a information about the pid file?
Hi Danny. Here's what I see: $ sudo rchal start Removing stale PID file /var/run/hal/haldaemon.pid. Starting HAL daemon done Yet after that, when I $(ps waux | grep hal), I see that there is no hal process running.
This is really strange. Could you start hal manually in this case (hald -- daemon=yes --retain-privileges)? Could you attach the output of lshal if HAL is correct running?
Sure. Here's what I see: .-(~)---------------------------------------------------------(gideon@localhost) - `--> sudo hald --daemon=yes --retain-privileges Password: .-(~)---------------------------------------------------------(gideon@localhost) - `--> ps waux | grep hal root 12149 9.1 0.3 5024 3720 ? Ss 06:04 0:01 hald -- daemon=yes --retain-privileges root 12174 0.0 0.0 1792 612 ? S 06:04 0:00 hald-addon- storage So, it starts. It did seem to take a good couple of seconds for hald to start. In /var/log/messages, I see this: Oct 14 06:04:12 linux sudo: gideon : TTY=pts/5 ; PWD=/home/gideon ; USER=root ; COMMAND=/usr/sbin/hald --daemon=yes --retain-privileges Oct 14 06:04:15 linux kernel: floppy0: Unable to grab DMA2 for the floppy driver I'm not sure if the floppy0 error has something to do with hal dying.... I'll attach the output of lshal next. Thanks for your help Danny!! =:)
Created attachment 54059 [details] output from "lshal > /tmp/lshal.out 2>&1"
Created attachment 54088 [details] output from sudo su -c "hald --daemon=no --retain-privileges --verbose=yes > /tmp/hald.out 2>&1 &" Okay, I just rebooted and noticed that hal did not start again at boot time. I ran the following command and am attaching the output. sudo su -c "hald --daemon=no --retain-privileges --verbose=yes > /tmp/hald.out 2>&1 &" I've noticed that the very last output from this has this: 08:34:12.343 [I] physdev.c:1443: phys_add: subsys=usb sysfs_path=/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2, parent=0x080a17b0 08:34:12.343 [E] util.c:409: Cannot open '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/serial' 08:34:12.343 [E] util.c:409: Cannot open '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/serial' scandir: No such file or directory 08:34:12.358 [I] device_info.c:1370: *** Matched file /usr/share/hal/fdi/information/10freedesktop/10-wireless-mice.fdi scandir: No such file or directory scandir: No such file or directory 08:34:12.364 [I] physdev.c:1368: Add callouts completed udi=/org/freedesktop/Hal/devices/usb_device_46d_c50e_noserial 08:34:12.364 [I] hald.c:89: Added device to GDL; udi=/org/freedesktop/Hal/devices/usb_device_46d_c50e_noserial 08:34:12.368 [E] util.c:684: Couldn't spawn 'hald-addon-usb-csr' err=Failed to execute child process "hald-addon-usb-csr" (No such file or directory)! HTH!!
This is what I supposed as a possible reason for the crash. There is already a YOU update in the pipe for this problem. see bug #121913. As workaround until the YOU update is available, remove /usr/share/hal/fdi/ information/10freedesktop/10-wireless-mice.fdi *** This bug has been marked as a duplicate of 121913 ***
CLosed.