From Bugzilla Helper: User-Agent: Opera/7.54 (X11; Linux i686; U) [en] Description of problem: Cannot start service ntpd (NTP daemon). Upon attempting to do so, this error is returned: ntpd failed. The error was: Starting ntpd: ntpd: error while loading shared libraries: libm.so.6: cannot open shared object file: Permission denied File permissions follow: [root@localhost lib]# pwd /lib [root@localhost lib]# ls -l libm* -rwxrwxrwx 1 root root 213376 Dec 21 05:04 libm-2.3.4.so lrwxrwxrwx 1 root root 13 Mar 6 22:45 libm.so.6 -> libm-2.3.4. so ... [root@localhost i686]# pwd /lib/i686 [root@localhost i686]# ls -l libm* -rwxrwxrwx 1 root root 213448 Dec 21 05:04 libm-2.3.4.so lrwxrwxrwx 1 root root 13 Mar 6 22:45 libm.so.6 -> libm-2.3.4. so ... [root@localhost tls]# pwd /lib/tls [root@localhost tls]# ls -l libm* -rwxrwxrwx 1 root root 215272 Dec 21 05:04 libm-2.3.4.so lrwxrwxrwx 1 root root 13 Mar 6 22:45 libm.so.6 -> libm-2.3.4. so Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Open �Start Here� 2.Open �System Settings� -> system-settings:/// 3.Choose �Server Settings� -> system-settings:///Server 4.Choose �Services� (and login as root) 5.In the �Service Configuration� window, select �ntpd� and attempt any of �Start�, �Stop�, or �Restart� Actual Results: This error message box appears: QUOTE ntpd failed. The error was: Starting ntpd: ntpd: error while loading shared libraries: libm.so.6: cannot open shared object file: Permission denied [FAILED] UNQUOTE (along with the red-X-stop-sign symbol and an �OK� button) Expected Results: Status window in �Service Configuration� window would report �ntpd started� or �ntpd running� Additional info: During boot up, there are a series of error messages while running non-interactive booting. This happens during the start up of various services. The error messages more than fill the screen and scroll by too rapidly to read. However, I recollect seeing the �libm.so.6� file indicated with wording to the effect that it cannot be opened or accessed. There may be several services or daemons not starting, but I�m not sure.
This sounds like a labeling problem. You need to relabel the file system in order to get SELinux working properly. The easiest way to do this is touch /.autorelabel reboot
I did ¨touch /.autorelabel¨ from a terminal, logged in as su. It seemed to take; at least, no error messages. Then I rebooted. The SELinux seems to be working ... found this in the /var/log/dmesg file (time stamp at time of most recent boot up): SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev hda2, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), not configured for labeling SELinux: initialized (dev hugetlbfs, type hugetlbfs), not configured for labeling SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts ... SELinux: initialized (dev hda1, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs ... SELinux: initialized (dev hdb1, type ext3), uses xattr Adding 522104k swap on /dev/hda3. Priority:-1 extents:1 SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts But, there is still an error ... shows red FAIL rather than green OK during several lines late in the boot process, shortly prior to localhost login ... scrolls by too fast to read it. I don´t know what log file to look in to see where such error messages might be captured. Basic problem, that ntpd won´t run, still exists. Still get the ¨libm.so.6: cannot open shared object file: Permission denied¨ error message. As far as I can see, libm.so.6 is a virtual link to libm-2. 3.4.so. There are at least three sets of these, in /lib, /lib/i686, and /lib/tls (that I know of) and all permissions are wide open (as shown earlier). I can´t understand why the shared object file cannot be opened.
Do you get any AVC messages in the /var/log/messages file>
I'm not sure what an AVC message is. When I look in /var/log I find four relevant files, messages messages.1 messages.2 messages.3 messages.4 I'm certain you know this, but they are system logs of activity in age order (messages.4 is oldest). Now the odd part: messages, which is the newest, does not reflect any activity since 27 FEB. I've had the machine on nearly daily since then. Inpsecting messages, I see what looks like usual type activity, including boot up sequences and shut down sequences. About the only thing out of the ordinary is a high number of "localhost kernel: eth0: link up." and "localhost kernel: eth0: link down." messages ... but then again that's about when I was switching to broadband and installing a wireless network. It took a few days of configuring, but once everything was running it has been without problems since. Should I be seeing "messages" files for any time the system is running?
William, try this command: grep 'avc: ' /var/log/messages
Here's the results [PASTE] [jwilliamcupp@Home_Linux ~]$ su Password: [root@Home_Linux jwilliamcupp]# date Tue Mar 22 23:37:59 EST 2005 [root@Home_Linux jwilliamcupp]# grep 'avc: ' /var/log/messages [root@Home_Linux jwilliamcupp]# [END PASTE] - Bill
I have upgraded to Fedora Core 4. This bug may be considered active for anyone who still works on FC3, but it is no longer of interest to me. For the record, the problem continues in FC4 (it is worse) and I think there are issues to be resolved in SELinux.
Look in /var/log/audit/audit.log for avc messages.