Bug 243482 - hald fails to start with error "Unable to open cache"
hald fails to start with error "Unable to open cache"
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
: 248636 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-06-08 18:23 EDT by Larry O'Leary
Modified: 2008-01-21 13:55 EST (History)
3 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-21 10:42:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
syslog output from hald-generate-fdi-cache failure (2.57 KB, text/plain)
2007-07-16 15:14 EDT, Ed Marshall
no flags Details

  None (edit)
Description Larry O'Leary 2007-06-08 18:23:51 EDT
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
session '/org/freedesktop/ConsoleKit/Session1'
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)
/usr/libexec/hald-generate-fdi-cache exited
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

How reproducible:
Perform hard disk install from F7 Live CD.
hald service fails to start at boot time.
Attempt to start manually, and status is FAILED.

Additional info:
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
expected location.

[root@localhost hald]# ls -al /var/cache/hald
total 896
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
Comment 1 Garry T. Williams 2007-06-16 08:49:46 EDT
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
correct user.

I did both installs from the *same* F7 Live CD.
Comment 2 Garry T. Williams 2007-07-06 13:34:18 EDT
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.
Comment 3 Ed Marshall 2007-07-16 15:14:13 EDT
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?
Comment 4 Ed Marshall 2007-07-16 15:19:08 EDT
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?
Comment 5 David Zeuthen 2007-07-16 15:41:59 EDT
Judging from comment 3, this looks like an SELinux issue. Dan, any ideas?
Comment 6 Daniel Walsh 2007-07-16 16:17:37 EDT
This is a labeling problem

restorecon -R -v /var/cache

Should fix this.
Comment 7 David Zeuthen 2007-07-16 16:37:44 EDT
(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?
Comment 8 Daniel Walsh 2007-07-16 16:40:04 EDT
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.
Comment 9 Ed Marshall 2007-07-16 17:06:34 EDT
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)
package installed.

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
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. :-)
Comment 10 David Zeuthen 2007-07-17 16:34:34 EDT
*** Bug 248636 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Walsh 2007-09-18 22:33:18 EDT
There have been several fixes to fixfiles that should fix this problem.

Fixed in policycoreutils-2.0.16-13.fc7.src.rpm

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