| Summary: | net-dns/ez-ipupdate - add systemd support | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Martin Väth <martin> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | systemd |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 448882 | ||
| Attachments: |
/usr/lib/tmpfiles.d/ez-ipupdate.conf
Patch for /etc/init.d/ez-ipupdate ez-ipupdate.service unit ez-ipupdate.service unit for current systemd |
||
Created attachment 370864 [details, diff]
Patch for /etc/init.d/ez-ipupdate
Created attachment 370866 [details]
ez-ipupdate.service unit
Why is PIDFILE still used in unit file? It is usually not needed when running in "simple" mode :/ (In reply to Pacho Ramos from comment #3) > Why is PIDFILE still used in unit file? IIRC the ExecReload command did not work reliably without it (but I might have made a mistake when testing, first.) I think MAINPID will still work ok without needing to specify PIDFile, could you confirm? (In reply to Pacho Ramos from comment #5) > I think MAINPID will still work ok without needing to specify PIDFile It might work, but it is less reliable, if e.g. ez-ipupdate creates subprocesses in certain cases, see e.g. http://lists.freedesktop.org/archives/systemd-devel/2013-February/009201.html "systemd can guess based on the cgroup's contents". As I said, I recall that I had some problems when testing first, though probably I will not be able to reproduce these anymore (perhaps also because systemd's cgroup handling has improved). Anyway, PIDFILE should be a "cleaner" solution than any guessing. PIDFile= makes sense only when Type=forking is used (this is noted in 'man systemd.service'). In Type=simple, the main PID is predefined by the initial fork(), so there's no need for PID file. Try this: [Unit] Description=ez-ipupdate: Check and update your IP to dynamic DNS Server After=syslog.target network.target auditd.service [Service] ExecStart=/usr/sbin/ez-ipupdate -f -R ez-ipupd -c /etc/ez-ipupdate/defaults.conf -F -b /var/cache/ez-ipupdate/defaults.cache ExecReload=/bin/kill -HUP $MAINPID KillSignal=SIGQUIT [Install] WantedBy=multi-user.target Also, are syslog and auditd really needed at "After"? :/ (In reply to Pacho Ramos from comment #8) > Try this: I must now use a router which does not distribute the IP to my local machine, so I cannot test. Anyway, I skipped through the ez-ipupdate source code, and with option -f no {v,}fork() is executed which might change the IP of that process which should receive the signal. So - at least with the current release of ez-ipupdate - it should be working. > Also, are syslog and auditd really needed at "After"? :/ I took this from some files I found on the net, but it seems to make sense. One would certainly want to log any attempt of ez-ipupdate to contact the remote service which might happen immediately at startup: One might even lose his dyndns account if ez-ipupdate contacts the service too often and one is not aware of it. The reason for audit is obviously similar. Created attachment 378018 [details] ez-ipupdate.service unit for current systemd I updated the ez-ipupdate.service file, taking the previous comments into account (in particular, comment #8, omitting the typo "-F"). Since current versions of systemd finally support networking and thus have obtained a corresponding network-online.target, ez-ipupdate.service should depend on this target and start only afterwards. (Since in any standard setup, network-online.target will directly or indirectly depend on logging, all other dependencies have been dropped.) +*ez-ipupdate-3.0.11.13.3_beta8-r2 (08 Jul 2014) + + 08 Jul 2014; Pacho Ramos <pacho@gentoo.org> + +ez-ipupdate-3.0.11.13.3_beta8-r2.ebuild, +files/ez-ipupdate.service, + -ez-ipupdate-3.0.11.13.3_beta8-r1.ebuild: + Add unit file (#501874 by Martin Vath), use readme.gentoo.eclass + |
Created attachment 370862 [details] /usr/lib/tmpfiles.d/ez-ipupdate.conf The script /etc/init.d/ez-ipupdate currently "manually" generates the directories /var/cache/ez-ipupdate and /var/run/ez-ipupdate The "modern" way to do this is to declare such directories/permissions in /usr/lib/tmpfiles.d/ez-ipupdate.conf and to rely on openrc/systemd/whatever to generate these directories. This not only simplifies the code for openrc but also provides a better compatibility with systemd and other init systems which provide support for tmpfiles.d When you are at it, maybe the obsolete /var/run location could also be changed to the modern location /run In addition, perhaps also a systemd unit could be added (with "inherit systemd" and "systemd_dounit ez-ipupdate.service") so that systemd users can use ez-ipupdate out-of-the-box. I attach the file for /usr/lib/tmpfiles.d, a patch for the initrd script, and a systemd unit ez-ipupdate.service. Note that in contrast to some ez-ipupdate.service files which can be found on the net, the attached unit follows gentoo's systemd policy to let the daemon be controlled directly by systemd instead of forking to the background.