Red Hat Bugzilla – Bug 243482
hald fails to start with error "Unable to open cache"
Last modified: 2008-01-21 13:55:29 EST
Description of problem:
hald will not start. It fails with the following error:
*** [DIE] mmap_cache.c:di_rules_init():68 : Unable to open cache
Complete output with verbosity turned on:
[root@localhost sbin]# hald --daemon=no --verbose=yes
17:15:11.719 [I] hald.c:529: hal 0.5.9
17:15:11.720 [I] hald.c:594: Will not daemonize
17:15:11.720 [I] hald_dbus.c:4807: local server is listening at
17:15:11.725 [I] ck-tracker.c:387: got seat '/org/freedesktop/ConsoleKit/Seat1'
17:15:11.730 [I] ck-tracker.c:317: got session
'/org/freedesktop/ConsoleKit/Session1' for seat '/org/freedesktop/ConsoleKit/Seat1'
17:15:11.732 [I] ck-tracker.c:270: Got active state (ACTIVE) and uid 0 on
17:15:11.732 [I] ck-tracker.c:338: Got all sessions on seat
17:15:11.732 [I] ck-tracker.c:414: Got seats
17:15:11.733 [I] ck-tracker.c:796: Got seats and sessions
Runner started - allowed paths are '/usr/libexec:/usr/lib/hal/scripts:/usr/bin'
17:15:11.736 [I] hald_runner.c:299: Runner has pid 3448
17:15:11.736 [W] ci-tracker.c:200: Could not get uid for connection:
org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name
'org.freedesktop.DBus': no such name
17:15:11.737 [E] hald_dbus.c:4462: Cannot get caller info for org.freedesktop.DBus
17:15:11.737 [I] hald_runner.c:180: runner connection is 0x83633c8
17:15:11.738 [I] mmap_cache.c:161: Regenerating fdi cache..
Run started hald-generate-fdi-cache (10000) (0)
! full path is '/usr/libexec/hald-generate-fdi-cache', program_dir is
17:15:11.748 [I] create_cache.c:608: Loading rules
17:15:11.957 [I] create_cache.c:674: preprobe: offset=00000014, size=3124
17:15:11.957 [I] create_cache.c:676: information: offset=00000c48, size=404468
17:15:11.957 [I] create_cache.c:678: policy: offset=0006383c, size=31440
17:15:11.957 [I] create_cache.c:680: Generating rules done (occupying 439052 bytes)
17:15:11.957 [I] mmap_cache.c:137: In regen_cache_cb exit_type=0, return_code=0
17:15:11.957 [I] mmap_cache.c:193: fdi cache generation done
17:15:11.957 [I] mmap_cache.c:251: cache mtime is 1180122636
*** [DIE] mmap_cache.c:di_rules_init():68 : Unable to open cache
Version-Release number of selected component (if applicable):
HAL package version: 0.5.9
Kernel version: 2.6.21-1.3194.fc7
Perform hard disk install from F7 Live CD.
hald service fails to start at boot time.
Attempt to start manually, and status is FAILED.
I have not attempted this installation on another machine as I do not have one
available at the moment.
/var is on its own partition.
After attempting to start hald, the cache file is being generated in the
[root@localhost hald]# ls -al /var/cache/hald
drwxr----- 2 root root 4096 2007-06-08 17:15 .
drwxr-xr-x 11 root root 4096 2007-06-07 20:50 ..
-rw-r--r-- 1 root root 439052 2007-06-08 17:15 fdi-cache
Got same problem after F7 install on Dell Latitude 610. The problem is
directory /var/cache/hald is owned by root and permissions 0700. When privilege
separation daemon runs as haldaemon, this directory is no longer readable.
The fix is to change the ownership of /var/cache/hald to haldaemon:haldaemon .
This bug is perplexing because it does not show up on Dell Dimension E520. On
that machine, immediately after F7 install, the directory is owned by the
I did both installs from the *same* F7 Live CD.
I installed F7 Live CD on a Sony Vaio FS640/W and the same problem occurred.
That is, the /var/cache/hald directory was owned by root:root and inaccessible
to haldaemon user.
Created attachment 159360 [details]
syslog output from hald-generate-fdi-cache failure
I'm seeing similar problems as well, which appear to be SELinux-related. I've
attached the syslog output running hald with "--verbose=yes", as well as the
avc denials. The directory in question, /var/cache/hald, looks like this:
# ls -lAFZd /var/cache/hald
drwx------ haldaemon haldaemon system_u:object_r:var_t /var/cache/hald/
# cd /var/cache/hald
# ls -lAFZ
-rw-r--r-- root root user_u:object_r:var_t fdi-cache
It was resolved by doing a chcon of /var/cache/hald/fdi-cache to
user_u:object_r:hald_cache_t. Perhaps the directory itself might benefit from
that as well?
I should probably note as well: I upgraded this machine from the previous FC6
install via yum, rather than via the installer. SELinux was enabled in both
cases, but perhaps the cache wasn't covered by policy previously?
Judging from comment 3, this looks like an SELinux issue. Dan, any ideas?
This is a labeling problem
restorecon -R -v /var/cache
Should fix this.
(In reply to comment #6)
> This is a labeling problem
> restorecon -R -v /var/cache
> Should fix this.
Wait. Things like this should work automatically without the end user having to
resort to such thus. I believe the problem is that the 'hal' RPM got upgraded
prior to the 'selinux-policy' or 'selinux-policy-targeted' packages. Edward, can
you check your logs and confirm this?
THe update of policy should have done this via checking the difference between
the two policies. But obviously this one was missed. I have no idea why and
believe that it would be very difficult to duplicate.
Here's the yum.log* results for anything matching hal or selinux for the FC7
update that I did (plus the most recent upgrade):
Jul 06 16:36:42 Updated: libselinux-devel.i386 2.0.14-2.fc7
Jul 06 16:40:05 Updated: libselinux.i386 2.0.14-2.fc7
Jul 06 16:42:26 Installed: hal-libs.i386 0.5.9-8.fc7
Jul 06 16:48:37 Updated: libselinux-python.i386 2.0.14-2.fc7
Jul 06 16:49:50 Updated: selinux-policy.noarch 2.6.4-23.fc7
Jul 06 16:54:38 Updated: selinux-policy-targeted.noarch 2.6.4-23.fc7
Jul 06 16:55:03 Installed: hal.i386 0.5.9-8.fc7
Jul 06 16:55:15 Installed: hal-info.noarch 20070516-2.fc7
Jul 16 10:31:54 Updated: selinux-policy.noarch 2.6.4-26.fc7
Jul 16 10:33:05 Updated: selinux-policy-targeted.noarch 2.6.4-26.fc7
What's interesting is that yum recorded it as an install rather than an update,
but if I check today, there's only a single hal (or hal-info, or hal-libs)
Hmm. One thing of interest: I seem to recall doing a smoltSendUpdate after
finishing the FC7 upgrade, and it worked. (That's what initially alerted me to
the problem: smolt couldn't connect to hald today when I tried to manually run
it.) Does smolt.fedoraproject.org retain a history of such things? (If so, I
could supply the UUID of this machine to help track that down, if you're
The versions I was coming from (in FC6) were:
Jan 08 08:40:29 Updated: hal.i386 0.5.8.1-6.fc6
Jan 18 17:46:19 Updated: libselinux.i386 1.33.4-2.fc6
Jan 18 17:47:38 Updated: libselinux-devel.i386 1.33.4-2.fc6
Jan 18 17:48:03 Updated: libselinux-python.i386 1.33.4-2.fc6
Jun 27 07:15:19 Updated: selinux-policy.noarch 2.4.6-75.fc6
Jun 27 07:15:51 Updated: selinux-policy-targeted.noarch 2.4.6-75.fc6
Hope this helps. :-)
*** Bug 248636 has been marked as a duplicate of this bug. ***
There have been several fixes to fixfiles that should fix this problem.
Fixed in policycoreutils-2.0.16-13.fc7.src.rpm