[Dnsmasq-discuss] systemd service improvements

Craig Andrews candrews at integralblue.com
Tue Jul 5 21:28:14 BST 2016

On 30.06.2016 17:39, Kurt H Maier wrote:
> On Thu, Jun 30, 2016 at 05:19:54PM -0400, Craig Andrews wrote:
>> I have no argument against only installing the systemd unit if a
>> configure flag is specified. Many pieces of software do it that way - 
>> I
>> think the important thing is that it's available from dnsmasq. So I
>> rescind my thought to install it unconditionally.
> What would the configure flag be passed to?

The "make" invocation. Just like how there is a "-DHAVE_DNSSEC" option, 
there could be a "-DHAVE_SYSTEMD" one.

> It would take more lines of code to modify the build process to suit
> this than it would just to write the unit file, and then you'd still
> have to rewrite the unit file for each distro.

The point isn't (necessarily) to conserve lines of code - the point is 
to have one place for distributions/users to collaborate in order to 
best develop and maintain this portion of the project. And each distro 
does not (and absolutely should not) rewrite the unit file. (Would you 
be happy if each distro patched dnsmasq? Same thing.)

> The traditional allocation of init responsibilities has always been 
> such
> as to free the upstream developer from the administrative minutiae by
> devolving the systems management functions to those whose experience 
> and
> daily operations have better formed them for the performance of such
> maintenance takss, thereby releasing the upstream developers for the
> more task-specific duties and deliberations.

Agreed. Systemd advances the situation by making it consistent and 
easier to manage these kinds of operations by using these short, 
readable, not many lines of code files that work across distros. 
Upstream is free to not worry if distros are doing something bizarre in 
their init process; upstream can trust that all distros are doing the 
same thing, giving upstream one (signficant) less thing to worry about.

Right now, note how each of these distribution's systemd units are 

The differences are in paths (a Makefile can eliminate those difference) 
and different security features (which are only different because some 
distros didn't notice some security features).

Distros are trying to use upstream units and get upstreams to include 
* Fedora: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files 
"Ideally, systemd unit files are reusable across distributions and 
shipped with the upstream packages. Please consider working with 
upstream to integrate the systemd files you prepare in the upstream 
* https://wiki.archlinux.org/index.php/DeveloperWiki:Systemd#Units "Use 
the upstream unit files whenever they exist"

A growing number of projects (big and small) have upstreamed systemd 
units, such as:
* bluez / Linux Bluetooth
* Tor
* MariaDB
* netdata
* lirc
* php
* memcached

> In short, I still think a generic unit file in /contrib is best, and
> people who want to use it will be okay if they have to copy it where
> their OS wants it.  dnsmasq runs in a lot of places systemd doesn't, so
> systemd is not to be taken as given.
> khm

I agree systemd isn't a given (again, my apologies once again for 
suggesting that units are installed unconditionally). However, the file 
does need to be customized for install paths and features (ex -DHAVE_) 
which the Makefile already does, so the file shouldn't in /contrib - I 
think it should be with the rest of the source, and conditionally 
processed and installed to the correct location by the Makefile.

I modified the Makefile and added the systemd unit. I'm not a Make 
expert, so I apologize for the errors I've very likely made. With this 
patch, you can run (for example):
	make COPTS="-DHAVE_DBUS -DHAVE_SYSTEMD" all install
and you'll get a dnsmasq.system file created, customized, and installed 
to the correct location (for any distribution). While I was in there, I 
also made the Makefile (conditionally, if -DHAVE_DBUS is provided) 
install the dbus service configuration.

I'm eager to hear thoughts about this approach.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnsmaq-install-systemd-dbus-configurations.diff
Type: text/x-diff
Size: 4491 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160705/f3c795ba/attachment.diff>

More information about the Dnsmasq-discuss mailing list