Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 144625 - hald freezes on hal-hotplug-map callout
hald freezes on hal-hotplug-map callout
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: David Zeuthen
Depends On:
  Show dependency treegraph
Reported: 2005-01-09 18:45 EST by Sean Middleditch
Modified: 2013-03-05 22:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-21 12:54:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log of strace hald --daemon=no --verbose=yes (93.77 KB, application/x-gzip)
2005-01-09 18:48 EST, Sean Middleditch
no flags Details
log of: hald --daemon=no --verbose=yes (56.17 KB, text/plain)
2005-01-13 16:25 EST, Sean Middleditch
no flags Details
log of: strace hald --daemon=no (690 bytes, text/plain)
2005-01-13 16:26 EST, Sean Middleditch
no flags Details
*correct* log of: strace hald --daemon=no (52.33 KB, application/x-gzip)
2005-01-13 16:29 EST, Sean Middleditch
no flags Details

  None (edit)
Description Sean Middleditch 2005-01-09 18:45:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041220 Epiphany/1.4.7

Description of problem:
hald started freezing on me after a hard reboot on the hal-hotplug-map
callout.  I completely removed and reinstalled hal in case something
had become corrupted (yes, using a journalad FS, XFS in particular)
but that changed nothing.

An strace on the executable shows it freezing after forking the
callout and calling write().  The callout finishes and is left in a
zombie state.  Presumably (I don't know the code) HAL is expecting to
write something to the child and is getting stuck in a race condition
when it exits unexpectedly.

Will attach a log of:
strace /usr/bin/hald --daemon=no --verbose=yes

Because HAL never finishes initializing, no HAL-using components work.
 In particular, Nautilus/gnome-vfs-daemon start behaving very badly. 
(Will file a separate bug.)

Version-Release number of selected component (if applicable):
hal-0.4.2.cvs20041210-1 dbus-0.22-12

How reproducible:

Steps to Reproduce:
1. start HAL

Additional info:
Comment 1 Sean Middleditch 2005-01-09 18:48:39 EST
Created attachment 109543 [details]
log of strace hald --daemon=no --verbose=yes
Comment 2 David Zeuthen 2005-01-13 14:10:55 EST
Could you test this against hal-0.4.5; I've made some fixes to the
callout code that I think will fix this. 0.4.5 is available in both
Rawhide and as a FC3 update.

Comment 3 Sean Middleditch 2005-01-13 16:25:34 EST
Created attachment 109739 [details]
log of: hald --daemon=no --verbose=yes
Comment 4 Sean Middleditch 2005-01-13 16:26:01 EST
Created attachment 109740 [details]
log of: strace hald --daemon=no
Comment 5 Sean Middleditch 2005-01-13 16:27:14 EST
above two logs are from hal-0.4.5-1, still seems to lock up.
Comment 6 Sean Middleditch 2005-01-13 16:29:06 EST
Created attachment 109741 [details]
*correct* log of: strace hald --daemon=no
Comment 7 David Zeuthen 2005-01-17 15:45:53 EST
Is the hald process left in the D state?
Comment 8 David Zeuthen 2005-03-21 12:54:02 EST
There is no hal-hotplug-map callout in the latest hal in Rawhide so I can now
close this bug :-)

Anyway, now that hal is more careful wrt handling hardware, this problem
shouldn't occur anymore. If it does, feel free to reopen this bug.

Note You need to log in before you can comment on or make changes to this bug.