Opened a new bug as still present in Fedora 20. I can confirm that the steps as reported in the original bug resolves the problem: # mkdir /var/run/ddclient # chown ddclient:ddclient /var/run/ddclient so presumably the RPM needs to be modified so the directory is created to allow the service to start? +++ This bug was initially created as a clone of Bug #860310 +++ Description of problem: systemd is unable to start the ddclient service. there are bugs in the ddclient.service file Version-Release number of selected component (if applicable): ddclient-3.8.1-3.fc17.noarch How reproducible: systemctl start ddclient.service Steps to Reproduce: 1. systemctl start ddclient.service 2. 3. Actual results: ddclient.service - A Perl Client Used To Update Dynamic DNS Loaded: loaded (/usr/lib/systemd/system/ddclient.service; enabled) Active: failed (Result: exit-code) since Tue, 25 Sep 2012 10:16:26 -0400; 6min ago Process: 1882 ExecStartPre=/bin/touch /var/cache/ddclient/ddclient.cache (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/ddclient.service Expected results: ddclient should start. There are 2 problems. First, the ownership of the /var/cache/ddclient/ddclient.cache is incorrect. The rpm installs it owned by user root and group root, but the systemd unit file is running as ddclient:ddclient. So the rpm spec file needs to be changed to install this file with the proper ownership. However, after running chown ddclient:ddclient /var/cache/ddclient/ddclient.cache, the service still does not start properly. It hangs for quite some time, and then gives an error: [root@dsbh dschorr]# systemctl start ddclient.service Job failed. See system journal and 'systemctl status' for details. [root@dsbh dschorr]# systemctl status ddclient.service ddclient.service - A Perl Client Used To Update Dynamic DNS Loaded: loaded (/usr/lib/systemd/system/ddclient.service; enabled) Active: failed (Result: timeout) since Tue, 25 Sep 2012 10:28:27 -0400; 14s ago Process: 3771 ExecStart=/usr/sbin/ddclient $DDCLIENT_OPTIONS (code=exited, status=0/SUCCESS) Process: 3768 ExecStartPre=/bin/touch /var/cache/ddclient/ddclient.cache (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/ddclient.service Sep 25 10:26:58 dsbh ddclient[3771]: stat() on closed filehandle FD at /usr...6. Sep 25 10:26:58 dsbh ddclient[3771]: Use of uninitialized value $mode in bi...7. Sep 25 10:26:58 dsbh ddclient[3771]: readline() on closed filehandle FD at ...9. Sep 25 10:26:58 dsbh ddclient[3771]: WARNING: file /etc/ddclient.conf: Can...d) This rpm is totally broken. I'm not sure how to fix this problem. Additional info: --- Additional comment from Andrew J. Schorr on 2012-09-25 10:41:39 EDT --- Oops, I see that the 2nd problem was caused by my own permissions problem (my /etc/ddclient.conf file was not readable by user ddclient). Fixing the ownership of /var/cache/ddclient/ddclient.cache fixes the bug. --- Additional comment from Rob on 2013-01-17 22:04:21 EST --- ddclient-3.8.1-3.fc17.noarch is still broken as of Jan. 18 2013, even after fixing the ownership of /var/cache/ddclient/ddclient.cache. When starting the service, it hangs and exits as follows: # service ddclient start Redirecting to /bin/systemctl start ddclient.service Job failed. See system journal and 'systemctl status' for details. However, when manually I do: # mkdir /var/run/ddclient # chown ddclient:ddclient /var/run/ddclient the service starts as expected! I assume another fix is needed in the RPM package. R. --- Additional comment from Rob on 2013-01-17 22:21:59 EST --- (In reply to comment #2) > ddclient-3.8.1-3.fc17.noarch is still broken as of Jan. 18 2013, even after > fixing the ownership of /var/cache/ddclient/ddclient.cache. > > When starting the service, it hangs and exits as follows: > > # service ddclient start > Redirecting to /bin/systemctl start ddclient.service > Job failed. See system journal and 'systemctl status' for details. > > However, when manually I do: > > # mkdir /var/run/ddclient > # chown ddclient:ddclient /var/run/ddclient > > the service starts as expected! > > I assume another fix is needed in the RPM package. I forgot that /var/run is not a fixed directory anymore, but created on the fly at boot by /etc/tmpfiles.d/ddclient , which has the proper settings. However, when installing the RPM package, this 'tmpfile' is not there yet (a reboot is needed....). Hence, the errors with the service. I guess the RPM package should then create the ddclient file in the /var/run directory (with proper ownership!), so that the ddclient package becomes usable immediately after the installation without the need of a reboot..... R. --- Additional comment from Rob on 2013-01-17 22:23:14 EST --- (In reply to comment #2) > ddclient-3.8.1-3.fc17.noarch is still broken as of Jan. 18 2013, even after > fixing the ownership of /var/cache/ddclient/ddclient.cache. > > When starting the service, it hangs and exits as follows: > > # service ddclient start > Redirecting to /bin/systemctl start ddclient.service > Job failed. See system journal and 'systemctl status' for details. > > However, when manually I do: > > # mkdir /var/run/ddclient > # chown ddclient:ddclient /var/run/ddclient > > the service starts as expected! > > I assume another fix is needed in the RPM package. I forgot that /var/run is not a fixed directory anymore, but created on the fly at boot by /etc/tmpfiles.d/ddclient , which has the proper settings. However, when installing the RPM package, this 'tmpfile' is not there yet (a reboot is needed....). Hence, the errors with the service. I guess the RPM package should then create the ddclient file in the /var/run directory (with proper ownership!), so that the ddclient package becomes usable immediately after the installation without the need of a reboot..... R. --- Additional comment from Rob on 2013-01-17 22:33:53 EST --- On another note: Remove in /etc/sysconfig/ddclient the line: DDCLIENT_OPTIONS="-daemon 300" because the default config file in /etc/ddclient.conf already has daemon=300 Changing the time in /etc/ddclient.conf has no effect as the setting in /etc/sysconfig/ddclient overrides the setting in the config file! If you want to demonstrate the use of /etc/sysconfig/ddclient, then better use instead the default config file location: DDCLIENT_OPTIONS="-file /etc/ddclient.conf" because this setting is independent of the settings in the config file. R. --- Additional comment from J Chapin on 2013-02-08 09:47:39 EST --- This bug is in Fedora 18, as well. --- Additional comment from Benny on 2013-02-24 19:10:20 EST --- Confirmed, still present in F18... As a workaround you can start ddclient with rc.local in /etc/rc.d/ rc-local.service --- Additional comment from Fedora End Of Life on 2013-07-03 22:54:32 EDT --- This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. --- Additional comment from Fedora End Of Life on 2013-08-01 05:42:33 EDT --- Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I never wanted this package, it was given to me I think due to a misunderstanding of http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/197959 . Re-assigning to cicku (Christopher Meng), who seems to be taking care of this for 19 and 20. Christopher, I granted you approvecommits and approveacls on the package in pkgdb, so you should be able to 'take' it from me now too.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.