[Dnsmasq-discuss] systemd service improvements
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 -
>> 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
> as to free the upstream developer from the administrative minutiae by
> devolving the systems management functions to those whose experience
> 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
> 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.
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...
Size: 4491 bytes
Desc: not available
More information about the Dnsmasq-discuss