Bug 787477

Summary: chronyd fails to start via systemctl
Product: [Fedora] Fedora Reporter: Mike C <mike.cloaked>
Component: chronyAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: andreas.bierfert, dwalsh, johannbg, metherid, mlichvar, mschmidt, notting, plautrba, systemd-maint
Target Milestone: ---Keywords: SELinux
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 11:14:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
chrony.conf as used when chrony.service fails to start none

Description Mike C 2012-02-05 15:31:55 UTC
Description of problem:
systemctl start chronyd.service fails with:

[root@daviesmachine ~]# systemctl start chronyd.service
Job failed. See system logs and 'systemctl status' for details.
[root@daviesmachine ~]# systemctl status chronyd.service
chronyd.service - NTP client/server
	  Loaded: loaded (/lib/systemd/system/chronyd.service; disabled)
	  Active: failed since Sun, 05 Feb 2012 15:03:44 +0000; 5s ago
	 Process: 1676 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers (code=exited, status=1/FAILURE)
	 Process: 1673 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS (code=exited, status=0/SUCCESS)
	 Process: 1667 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey (code=exited, status=0/SUCCESS)
	Main PID: 1675 (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/chronyd.service


Version-Release number of selected component (if applicable):
systemd-37-11.fc16.i686

How reproducible:
Every time

Steps to Reproduce:
1. systemctl start chronyd.service
2. chronyd does not start
3.
  
Actual results:
Job failed. See system logs and 'systemctl status' for details.

Expected results:
Expect chronyd.service to start normally

Additional info:

F16 fully up to date - 

Will attach chrony.conf shortly

Interestingly running chronyd manually from a terminal window does start
the daemon but there is an selinux avc.

SELinux is preventing /usr/sbin/chronyd from getsession access on the None

If you believe that chronyd should be allowed getsession access on the  <Unknown> by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep chronyd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:chronyd_t:s0
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Objects                 [ None ]
Source                        chronyd
Source Path                   /usr/sbin/chronyd
Port                          <Unknown>
Host                          daviesmachine
Source RPM Packages           chrony-1.26-3.20110831gitb088b7.fc16.i686
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-75.fc16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing

However the daemon does run when executed from the terminal.

I am not sure if selinux, chrony or systemd are the main issue here?

Comment 1 Mike C 2012-02-05 15:33:54 UTC
Created attachment 559470 [details]
chrony.conf as used when chrony.service fails to start

Comment 2 Daniel Walsh 2012-02-06 18:51:26 UTC
Could you attach the output of 

ausearch -m avc -ts recent 

After the chronyd fails to start.

Does it fail to start in permissive mode?

Comment 3 Mike C 2012-02-06 19:16:35 UTC
Dan I am really sorry but this machine is one that I maintain for a relative who lives 200 miles from me and has just left to go back home after a weekend visit during which I updated the machine - and they only connect to the net via a tethered phone so I can't ssh in to run that test until they next visit me. They are not admin expert enough to run the test on my behalf - 

However I did set the machine to permissive two days back when I first came across the issue, as a test, and it was exactly the same (i.e. trying to start the daemon with systemctl) - and for good measure I stopped iptables as well and it was also exactly the same - which was why I was not convinced that the main problem was selinux related - unfortunately I did not run the chronyd command manually with selinux set permissive - and that may well have been selinux related but was a secondary issue since I wanted the machine to go back with them with a functional chronyd started with systemd at boot - 

The machine is i386 and had a standard f16 install which until now had no issues related to chrony as far as I know.

If progress on this needs the output of the command you give in #2 then unfortunately it will need to wait until their next visit around the end of March.

It would be useful if anyone else had a similar or the same problem who could progress this?

Comment 4 Daniel Walsh 2012-02-06 20:11:59 UTC
I just installed and started it on F17/Rawhide and it seems to be working.

Comment 5 Andreas Bierfert 2012-02-06 20:59:36 UTC
Seeing the same on rawhide (chrony-1.26-4.20110831gitb088b7.fc17.x86_64) with selinux disabled on boot.

Active: failed since Mon, 06 Feb 2012 21:29:09 +0100; 27min ago
	 Process: 19861 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers (code=exited, status=1/FAILURE)

Comment 6 Michal Schmidt 2012-02-07 08:23:21 UTC
Did it log any errors to /var/log/messages?

Comment 7 Miroslav Lichvar 2012-02-07 12:30:06 UTC
Is there a server in /var/lib/dhclient/chrony.servers.* which is also in /etc/chrony.conf? That would be a dup of bug #787042.

Comment 8 Andreas Bierfert 2012-02-07 21:58:46 UTC
It is a dup of #787042 for me. Both chrony.servers.{eth0,eth1} had the same server ip...

Comment 9 Miroslav Lichvar 2012-02-10 17:24:03 UTC
Here is the package fixing bug #787042.

http://koji.fedoraproject.org/koji/buildinfo?buildID=298706

Comment 10 Miroslav Lichvar 2012-08-07 11:14:59 UTC
I'm assuming this is a dup of bug #787042 for the original reporter too. Please reopen if that's not the case.

*** This bug has been marked as a duplicate of bug 787042 ***