unbound and systemd

[Tomas Hozza]

On 18.10.2015 16:34, Sami Kerola via Unbound-users wrote:
> On 17 October 2015 at 01:55, Paul Wouters <paul at nohats.ca> wrote:
> > On Fri, 16 Oct 2015, W.C.A. Wijngaards via Unbound-users wrote:
> >
> >> Your patch seems to want to customize the compile itself, and
> >> always-active, install for systemd.  This is because the Makefile is
> >> also trying to do the package install.  Most package systems can pick
> >> up files and install them, especially system files like init.d/rc.d.
> >> It would be inappropriate (I think) for Unbound's Makefile to install
> >> these files, and even more so, install them when systemd is not
> >> present.  So, I would leave those files in contrib, the Makefile then
> >> does not need any changes (I think).  A packager or package-script can
> >> then pick then up and install them.  Wouldn't that be cleaner and more
> >> portable?
> >
> >
> > But that would cause a "make install" to leave something on the
> > filesystem that is not ready to be enabled as a service or started on
> > boot. So make install does need to make some decision on what init
> > system support files to install.
> >
> > For libreswan, we detect the init system, and we provide an override.
> > Our detection script supports systemd, sysvinit, upstart and openrc. See:
> >
> > https://github.com/libreswan/libreswan/blob/master/packaging/utils/lswan_detect.sh
> >
> > But we might be a little more linux-centric then you are.
> >
> > We allow an override running make with INITSYSTEM=sysvinit which is used
> > to install sysvinit support on RHEL6 (which technically has upstart but
> > no one uses it).
>
> Few updates to my changes.
>
> 1. pkg-config is now used the usual way. If this turns out to be bad
> idea after all there is 'systemd-no-pkg-config' branch in my remote
> git that has the previous style m4 stuff.
>
> 2. If socket activation does not work user will get an error followed
> by normal socket open.
>
> 3. New configuration option 'use-systemd' is added, and it does what
> one would expect.
>
> 4. Appropriate error message is added when systemd is enabled, but not running.
>
> 5. The systemd is not consulted for outside_network sockets.
>
> 6. The service and socket contrib files are still installed. I think
> this is right thing to do, but as Paul said it might be best to have
> discussion and align code accordingly. BTW if the service and socket
> files get to be installed then I think the configuration example ought
> to be made more intelligent to contain use-systemd and do-daemonize
> options with environment specific values.
>
> ----------------------------------------------------------------
> The following changes since commit 7430760ce6401834cd0414165eb13344c6c6f47e:
>   1.5.6rc1 release tag has been created (2015-10-15 11:44:24 +0000)
> are available in the git repository at:
>   git://github.com/kerolasa/unbound.git systemd
> for you to fetch changes up to 1b2ddd76c803d1581c6f87cdc4ae6911d1270c1b:
>   systemd: use-systemd config bison and yacc changes (2015-10-18 15:11:45 +0100)
> ----------------------------------------------------------------
> Sami Kerola (13):
>       build-sys: run autoreconf -f version 1.5
>       build-sys: add some autotools output files to .gitignore
>       build-sys: add systemd support to autotools
>       build-sys: rerun autoreconf -f && libtoolize -f
>       build-sys: add ./configure output files to .gitignore
>       build-sys: update .gitignore after build
>       systemd: make systemd activation work for udp sockets
>       systemd: make systemd activation work for tcp sockets
>       systemd: make systemd activation work for unix sockets
>       systemd: add service and socket files
>       systemd: add state notifications
>       systemd: add use-systemd configuration option
>       systemd: use-systemd config bison and yacc changes
>

Hi.

I went slightly through your service file. I wanted to point out
that in Fedora we have systemd service files for years and it works
for us nicely. There were some real world issues and the current
state of unit files is outcome of the feedback we had from users.
Unfortunately when seeing your email I realized we never contributed
them back, like we did for dnssec-trigger.

You can check the unit files in master branch of Fedora git:
http://pkgs.fedoraproject.org/cgit/unbound.git/tree/

Couple of things we have and you miss (from what I looked on github)
are:

- timer unit for unbound-anchor to update the trust anchor accordingly
  to RFC 5011
- one shot unit for generating keys used by unbound-control
- for reloading the daemon we use 'unbound-control reload'

I have one thing I would like to confirm.

When the systemd feature will be enabled, will unbound work also without
socket activation by systemd? IOW directly started by unbound.service.
>From what I checked if the 'use-systemd' is set to 'no' it should work
just fine. The socket activation from systemd will not be used, but the
notifications to systemd will be still used, right?

Thanks.

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+2 (CEST)
Red Hat Inc.                 http://cz.redhat.com