Description of problem: Hello, After upgrading from FC6 to F6.93, I tried to run smoltSendProfile, a script from the smolt package. However, I get this: [root@gateway1 ~]# smoltSendProfile Traceback (most recent call last): File "/usr/bin/smoltSendProfile", line 95, in <module> profile = smolt.Hardware() File "/usr/share/smolt/client/smolt.py", line 258, in __init__ mgr = self.dbus_get_interface(systemBus, 'org.freedesktop.Hal', '/org/freedesktop/Hal/Manager', 'org.freedesktop.Hal.Manager') File "/usr/share/smolt/client/smolt.py", line 294, in dbus_get_interface proxy = bus.get_object(service, object) File "/usr/lib/python2.5/site-packages/dbus/_dbus.py", line 410, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 230, in __init__ _dbus_bindings.UInt32(0)) File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 169, in __call__ reply_message = self._connection.send_message_with_reply_and_block(message, timeout) dbus.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Hal was not provided by any .service files Regards, Răzvan Version-Release number of selected component (if applicable): smolt-0.9.7.1-4.fc7 hal-0.5.9-8.fc7 dbus-1.0.2-4.fc7 kernel-2.6.20-1.2948.fc6 kernel-2.6.21-1.3175.fc7 How reproducible: Sometimes. Actual results: It seems a module is missing. Expected results: smoltSendProfile should send hardware profile to the smolt server. Additional info: Please see https://hosted.fedoraproject.org/projects/smolt/ticket/8
Hello, I get the same on Fedora 7, after the official launch, on many Fedora boxes. Still no solution ? Regards, Răzvan
Two questions 1. What is the output of 'chkconfig --list haldaemon' 2. What is the output of 'lshal' Thanks.
Hello, Here they are: [root@gateway1 ~]# chkconfig --list haldaemon haldaemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off [root@gateway1 ~]# lshal Could not initialise connection to hald. Normally this means the HAL daemon (hald) is not running or not ready. Trying to manually (re)start haldaemon, service is not starting: However, I didn't do any manual modification on these machines (beyond a default instalation of Fedora + online updates). The only particularity is that they were upgraded from FC6 to F7 via yum and not via CD. Regards, Răzvan
Are you getting valid output from: /usr/bin/lshal
Please attach the output of /usr/sbin/hald --daemon=no --verbose=yes when running as root. Also, what versions of hal and hal-info RPM's are you using? Thanks.
I'm running hal-0.5.9-8.fc7 hal-info-20070516-2.fc7 Could you please specify a way to capture the output of /usr/sbin/hald --daemon=no --verbose=yes in a text file ? Using a standard redirection ( > ) doesn't work and that's a lot of output... (sorry, I'm not a programmer...) Regards, Răzvan
Do this as root /usr/sbin/hald --daemon=no --verbose=yes > hald_out.txt 2>&1 If the command doesn't return it's good. Then go to another terminal and type 'lshal > lshal_out.txt'. Attach both hald_out.txt and lshal_out.txt to this bug. (Also please avoid sending me mail directly on the bug report; I suspect the one from 'root <root.ro>' to davidz was from you) Thanks.
Also, what is the output of 'getenforce' (as root)? Thanks.
Created attachment 156134 [details] Output from hald
Created attachment 156135 [details] Output from lshal
Output from getenforce is "Enforcing". Putting "setenforce 0" doesn't change te situation. Sorry for the direct mail - it was a desperate try ;-) Răzvan
OK, so this is what I gather from comment 9 and comment 10 1. Starting hald manually works fine and from comment 11 2. You're running in SELinux enforcing mode > Putting "setenforce 0" doesn't change te > situation. Just to verify, try as root setenforce 0 /etc/init.d/haldaemon start lshal Thanks!
Created attachment 156171 [details] Other output from lshal Hello, Yes, it *is* selinux-related: the daemon starts now (please see the attached file). But it's very strange, since I've *verified* this last time, when I first wrote and *it didn't* worked... Regards, Răzvan
Possibly you need to relabel the whole file system; either way, reassigning to the appropriate SELinux component. Thanks for using Fedora.
Could you attach your /var/log/audit/audit.log
Hello, Here is the relevant entry: type=AVC msg=audit(1181463991.299:120): avc: denied { getattr } for pid=7414 comm="hald" name="fdi-cache" dev=sda2 ino=9689858 scontext=user_u:system_r:hald_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1181463991.299:120): arch=c000003e syscall=4 success=no exit=-13 a0=43b10f a1=7fffe4bfbe20 a2=7fffe4bfbe20 a3=6569a0 items=0 ppid=7413 pid=7414 auid=500 uid=68 gid=68 euid=68 suid=68 fsuid=68 egid=68 sgid=68 fsgid=68 tty=(none) comm="hald" exe="/usr/sbin/hald" subj=user_u:system_r:hald_t:s0 key=(null) type=AVC_PATH msg=audit(1181463991.299:120): path="/var/cache/hald/fdi-cache" type=AVC msg=audit(1181463991.303:121): avc: denied { write } for pid=7416 comm="hald-generate-f" name="hald" dev=sda2 ino=9690180 scontext=user_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir type=SYSCALL msg=audit(1181463991.303:121): arch=c000003e syscall=2 success=no exit=-13 a0=7fff68b82780 a1=242 a2=1a4 a3=0 items=0 ppid=7415 pid=7416 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="hald-generate-f" exe="/usr/libexec/hald-generate-fdi-cache" subj=user_u:system_r:hald_t:s0 key=(null) type=AVC msg=audit(1181463991.305:122): avc: denied { read } for pid=7414 comm="hald" name="fdi-cache" dev=sda2 ino=9689858 scontext=user_u:system_r:hald_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1181463991.305:122): arch=c000003e syscall=2 success=no exit=-13 a0=43b10f a1=0 a2=12 a3=2aaaabbc99d0 items=0 ppid=7413 pid=7414 auid=500 uid=68 gid=68 euid=68 suid=68 fsuid=68 egid=68 sgid=68 fsgid=68 tty=(none) comm="hald" exe="/usr/sbin/hald" subj=user_u:system_r:hald_t:s0 key=(null) Regards, Răzvan
The problem here is that /var/cache/hald is mislabeled. restorecon -R -v /var/cache/hald Did this dir get removed and added back? Somehow it got mislabled.
Hello, The system was upgraded via yum from Fedora Core 6 to Fedora 7. I didn't do any manual interventions other than the default ones, operated by rpm when upgrading the new selinux-policy-targeted. This happened on *many* systems, not on a single one. Is it possible that the rpm package somehow „forgets” to set the proper SELinux context for /var/cache/hald during upgrade ? The matter is not about doing a manual relabel after upgrade, but to unexpectedly inhibiting haldaemon. I will leave this open for the time being, until we learn this. Regards, Răzvan
I guess this is why upgrades are almost never fully supported. Problem is all directories in created are not necessarily labeled correctly during the upgrade. RHEL4-RHEL5 forces a relabel. So it is probably advisable to do a touch /.autorelabel reboot