Ask Your Question

chronyd.service failed

asked 2016-04-12 18:53:43 -0500

dagger gravatar image

When I run systemctl list-units | grep failed, one service is returned:

chronyd.service loaded failed failed NTP client/server

To get more details, I have run systemctl status chronyd.service -l and what is returned is:

● chronyd.service - NTP client/server

Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)

Active: failed (Result: exit-code) since Tue 2016-04-12 17:09:01 MDT; 24min ago

Process: 1225 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=1/FAILURE)

Apr 12 17:09:00 sager systemd[1]: Starting NTP client/server...

Apr 12 17:09:01 sager systemd[1]: chronyd.service: Control process exited, code=exited status=1

Apr 12 17:09:01 sager systemd[1]: Failed to start NTP client/server.

Apr 12 17:09:01 sager systemd[1]: chronyd.service: Unit entered failed state.

Apr 12 17:09:01 sager systemd[1]: chronyd.service: Failed with result 'exit-code'.

Apr 12 17:09:03 sager chronyd[1225]: Could not open configuration file /etc/chrony.conf

I do also recall seeing something about chronyd in an SELinux alert in the past about chronyd. When I open the SELinux Troubleshooter, there is indeed an entry about this service:

SELinux is preventing chronyd from read access on the file /etc/chrony.conf.

*Plugin restorecon (94.8 confidence) suggests *

If you want to fix the label. /etc/chrony.conf default label should be etc_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/chrony.conf

*Plugin catchall_labels (5.21 confidence) suggests *

If you want to allow chronyd to have read access on the chrony.conf file Then you need to change the label on /etc/chrony.conf Do # semanage fcontext -a -t FILE_TYPE '/etc/chrony.conf' where FILE_TYPE is one of the following: NetworkManager_tmp_t, abrt_helper_exec_t, abrt_tmp_t, abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_run_t, admin_crontab_tmp_t, afs_cache_t, alsa_tmp_t, amanda_tmp_t, antivirus_tmp_t, apcupsd_tmp_t, apmd_tmp_t, arpwatch_tmp_t, asterisk_tmp_t, auditadm_sudo_tmp_t, automount_tmp_t, awstats_tmp_t, bacula_tmp_t, bin_t, bitlbee_tmp_t, blueman_tmp_t, bluetooth_helper_tmp_t, bluetooth_helper_tmpfs_t, bluetooth_tmp_t, boinc_project_tmp_t, boinc_tmp_t, boot_t, bootloader_tmp_t, bugzilla_tmp_t, cardmgr_dev_t, ccs_tmp_t, cdcc_tmp_t, cert_t, cgroup_t, chrome_sandbox_tmp_t, chronyd_exec_t, chronyd_keys_t, chronyd_tmpfs_t, chronyd_var_lib_t, chronyd_var_run_t, cinder_api_tmp_t, cinder_backup_tmp_t, cinder_scheduler_tmp_t, cinder_volume_tmp_t, cloud_init_tmp_t, cluster_conf_t, cluster_tmp_t, cluster_var_lib_t, cluster_var_run_t, cobbler_tmp_t, cockpit_tmp_t, collectd_script_tmp_t, colord_tmp_t, comsat_tmp_t, condor_master_tmp_t, condor_schedd_tmp_t, condor_startd_tmp_t, conman_tmp_t, couchdb_tmp_t, courier_exec_t, cpu_online_t, crack_tmp_t, crond_tmp_t, crontab_tmp_t, ctdbd_tmp_t, cups_pdf_tmp_t, cupsd_lpd_tmp_t, cupsd_tmp_t, cvs_tmp_t, cyphesis_tmp_t, cyrus_tmp_t, dbadm_sudo_tmp_t, dbskkd_tmp_t, dbusd_etc_t, dcc_client_tmp_t, dcc_dbclean_tmp_t, dccd_tmp_t, dccifd_tmp_t, dccm_tmp_t, ddclient_tmp_t, deltacloudd_tmp_t, devicekit_tmp_t, dhcpc_state_t, dhcpc_tmp_t, dhcpd_tmp_t, dirsrv_tmp_t, dirsrvadmin_tmp_t, disk_munin_plugin_tmp_t, dkim_milter_tmp_t, dnssec_trigger_tmp_t, docker_tmp_t, dovecot_auth_tmp_t, dovecot_deliver_tmp_t, dovecot_tmp_t, drbd_tmp_t, etc_runtime_t, etc_t, exim_exec_t, exim_tmp_t, fail2ban_tmp_t, fail2ban_var_lib_t, fenced_tmp_t, file_context_t, firewalld_tmp_t, firewallgui_tmp_t, fonts_cache_t, fonts_t, fsadm_tmp_t, fsdaemon_tmp_t, ftpd_tmp_t, ftpdctl_tmp_t, games_tmp_t, games_tmpfs_t, gconf_tmp_t, geoclue_tmp_t, getty_tmp_t, git_script_tmp_t, gkeyringd_tmp_t, glance_registry_tmp_t, glance_tmp_t, glusterd_tmp_t, gpg_agent_tmp_t, gpg_pinentry_tmp_t, gpg_pinentry_tmpfs_t, gpm_tmp_t, gpsd_tmpfs_t, gssd_tmp_t, hostname_etc_t, hsqldb_tmp_t, httpd_php_tmp_t, httpd_suexec_tmp_t, httpd_tmp_t, inetd_child_tmp_t, inetd_tmp_t, init_tmp_t, initrc_tmp_t, ipsec_tmp_t, iptables_tmp_t, iscsi_tmp_t, jetty_tmp_t, kadmind_tmp_t, kdumpctl_tmp_t, kdumpgui_tmp_t, keystone_tmp_t, kismet_tmp_t, kismet_tmpfs_t, klogd_tmp_t, krb5_conf_t, krb5_host_rcache_t, krb5kdc_tmp_t, ktalkd_tmp_t, l2tpd_tmp_t, ld_so_cache_t, ld_so_t, ldconfig_tmp_t, lib_t, livecd_tmp_t, locale_t, logrotate_mail_tmp_t, logrotate_tmp_t, logwatch_mail_tmp_t, logwatch_tmp_t, lpd_tmp_t, lpr_tmp_t, lsassd_tmp_t, lsmd_plugin_tmp_t, lvm_tmp_t, machineid_t, mail_munin_plugin_tmp_t, mailman_cgi_tmp_t, mailman_mail_tmp_t, mailman_queue_tmp_t, man_cache_t, man_t, mandb_cache_t, mdadm_tmp_t, mediawiki_tmp_t, mock_tmp_t, mojomojo_tmp_t, mongod_tmp_t, mount_tmp_t, mozilla_plugin_tmp_t, mozilla_plugin_tmpfs_t, mozilla_tmp_t, mozilla_tmpfs_t, mpd_tmp_t, mplayer_tmpfs_t, mscan_tmp_t, munin_script_tmp_t, munin_tmp_t, mysqld_tmp_t, nagios_eventhandler_plugin_tmp_t, nagios_openshift_plugin_tmp_t, nagios_system_plugin_tmp_t, nagios_tmp_t, named_tmp_t, net_conf_t, netutils_tmp_t, neutron_tmp_t, nova_tmp_t, nsd_tmp_t, ntop_tmp_t, ntpd_tmp_t, nut_upsd_tmp_t, nut_upsdrvctl_tmp_t, nut_upsmon_tmp_t, nx_server_tmp_t, openshift_cgroup_read_tmp_t, openshift_cron_tmp_t ...

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2016-04-12 20:41:57 -0500

florian gravatar image

updated 2016-04-12 20:45:38 -0500

As you already found out, the problem is that chronyd can't access its own config file.

I would fix it by doing what SELinux Troubleshooter suggest starting with the restorecon command. Probably you just have a wrong label on that file. Did you disable SELinux some time in the past? That may cause it.

If you run it many of those label problems you can relabel your whole system by running sudo touch /.autorelabel

BTW: You can also use systemctl --failed to check on services...

edit flag offensive delete link more


Thanks for the response, @florian. I will run the restorecon command and see how that does. I have never knowlingly disabled SELinux, so I'm not sure why things would be mislabeled...

Is there any danger in running sudo touch /.autorelabel? Is that a good "periodic maintenance" thing to do?

Last, do you have any idea _why_ chronyd wouldn't be able to access its own config file by default? It seems like any application or service ought to be able to read its own config file...

dagger gravatar imagedagger ( 2016-04-12 21:40:23 -0500 )edit

Sure, chronyd must be able to read its config file. Reasons why this can happen are wrongly set file permissions, or wrong file labeling so that SELinux prevents access (that's what your SELinux Troubleshooter is saying in your case). The reason why this happened? No clue...

No danger of touch /.autorelabel that I am aware of but I would personally only run it if I came across several mislabeling issues, not as periodic maintenance. Mislabeling can also happen during a release upgrade process. Maybe you did that?

florian gravatar imageflorian ( 2016-04-12 21:48:55 -0500 )edit

I finally had a chance to run the restorecon command and restart. chrony.d no longer is listed as failed under systemctl --failed. Thanks @florian!

dagger gravatar imagedagger ( 2016-04-14 08:59:11 -0500 )edit

Question Tools



Asked: 2016-04-12 18:53:43 -0500

Seen: 2,906 times

Last updated: Apr 12 '16