Bug 860310 - ddclient systemd service does not start properly due to incorrect ownership of /var/cache/ddclient/ddclient.cache
ddclient systemd service does not start properly due to incorrect ownership o...
Status: NEW
Product: Fedora
Classification: Fedora
Component: ddclient (Show other bugs)
26
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-25 10:34 EDT by Andrew J. Schorr
Modified: 2017-06-18 22:54 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1167493 (view as bug list)
Environment:
Last Closed: 2013-08-01 05:42:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew J. Schorr 2012-09-25 10:34:55 EDT
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:
Comment 1 Andrew J. Schorr 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.
Comment 2 Rob 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.
Comment 3 Rob 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.
Comment 4 Rob 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.
Comment 5 Rob 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.
Comment 6 J Chapin 2013-02-08 09:47:39 EST
This bug is in Fedora 18, as well.
Comment 7 Benny 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
Comment 8 Fedora End Of Life 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.
Comment 9 Fedora End Of Life 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.
Comment 10 James (purpleidea) 2017-06-18 22:54:59 EDT
I think something has rotted with this service and it needs some love, because I'm experiencing issues on latest CentOS for example. They seem similar to what is described here.

Thanks!

Note You need to log in before you can comment on or make changes to this bug.