Description of problem: "systemctl start ddclient" hangs and then times out. Debug messages complain about not being able to create PID file. Version-Release number of selected component (if applicable): ddclient-3.9.1-8.el9.noarch.rpm How reproducible: Very Steps to Reproduce: 1.systemctl start ddclient 2. 3. Actual results: Hangs and times out. Expected results: A prompt Additional info: Removing the PIDfile=" from the /usr/lib/systemd/system/ddclient.service file fixes the problem. It looks like both ddclient and systemctl are vying to create the PID file, and the second one generates the error and times out. Possible conflict having pidfile specified in two config files (ddclient.conf and ddclient.service).
Unable to reproduce this. Installed ddclient-3.9.1-8.el9 on a CentOS Stream 9 machine. Ran 'systemctl start ddclient.service'. It started fine. Any more details on your situation? Perhaps you have made config file changes?
Our ddclient.conf is: daemon=600 # check every 300 seconds syslog=yes # log update msgs to syslog ssl=yes # mail=root # mail all msgs to root # mail-failure=root # mail failed update msgs to root pid=/var/run/ddclient.pid # record PID in file. # server=members.dyndns.com protocol=dyndns2 login=eolxxxxx password=xxxxxxxxx use=web, web=checkip.dyndns.com/, web-skip='IP Address:' # rafhost.dyndns.org
OK, I was able to reproduce using your config. Must be some sort of race condition or something. Anyway, it seems systemd type=forking is sort of discouraged now, and upstream ddclient switched it's example to use exec, so I've done that in rawhide. I'll backport it to epel9 after a bit.
Thanks for the update on forking. So, I noticed today that my ddclient.conf file, which has been migrated from el7 to el8 to el9, has a different pid directory (/var/run/ instead of /run/ddclient/). When I changed it to match the filename in your .service file, things worked. And your package has the same name in both files (/run/ddclient/ddclient.pid). I should have caught that earlier.
I had the exact same issue after upgrading to Fedora 42. The issue was solved with: sudo mkdir /etc/ddclient && sudo mv /etc/ddclient.conf /etc/ddclient/ Affects: ddclient-4.0.0-1.fc42.noarch (`rpm -ql ddclient` shows that the RPM still installs to /etc/ddclient.conf)
Sorry, Christopher, that bug was supposed to have been fixed by this update, which was stalled for F42 because someone had a problem on Silverblue: https://bodhi.fedoraproject.org/updates/FEDORA-2025-0a0a04ceb5