Home Forums MaraDNS and other support systemd unit for zoneserver

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #75
    pillarsdotnet
    Participant

    Curiously enough, starting zoneserver under systemd fails unless I run it as a child process.

    This fails:

    ExecStart=usr/sbin/zoneserver -f /etc/maradns/mararc

    But this succeeds:

    ExecStart=/usr/bin/strace -f /usr/sbin/zoneserver -f /etc/maradns/mararc

    This also succeeds:

    ExecStart=/bin/sh -c '/usr/sbin/zoneserver -f /etc/maradns/mararc'

    Here is some example journalctl output for the failing case:

    Sep 08 00:36:33 foundry.bobvincent.com zoneserver[123151]: Operation not permitted
    Sep 08 00:36:33 foundry.bobvincent.com systemd[1]: maradns-zoneserver.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED
    Sep 08 00:36:33 foundry.bobvincent.com systemd[1]: maradns-zoneserver.service: Failed with result 'exit-code'.

    Here is the output when running under /bin/sh:

    Sep 08 14:00:35 foundry.bobvincent.com systemd[1]: Started MaraDNS Zoneserver handles DNS zone transfers and any TCP DNS queries.
    Sep 08 14:14:41 foundry.bobvincent.com dash[136306]: Log: Root directory changed
    Sep 08 14:14:41 foundry.bobvincent.com dash[136306]: Log: Socket opened on TCP port 53
    Sep 08 14:14:41 foundry.bobvincent.com dash[136306]: Log: Root privileges dropped

    Setting the verbose_level = 4 did not affect the output during startup or failure.

    • This topic was modified 2 months, 2 weeks ago by pillarsdotnet.
    #77
    maradns
    Keymaster

    The entire system for starting up MaraDNS daemons was set up back in the days when System V Init was the standard way to starting up services, long before systemd was even a glint in Lennart Poettering and Kay Sievers’s eyes.

    That in mind, I’m not surprised that some of MaraDNS has a hard time starting up with systemd.

    The standard way to start up all MaraDNS services is to use the Duende daemonizer to make the service in question a daemon. For example, from a fresh compile of MaraDNS, in the tcp directory where zoneserver is compiled:

    duende zoneserver -f ../doc/en/examples/example_mararc

    So, I think the issue is that, here in 2020, we need to look in to getting things to work with systemd. At which point I am going to give you a rant:

    There are a number of different distributions of Linux out there, and they each have their own way of starting up and managing processes. Things got so messy, DJB gave up and created his own daemonizer and setup for starting and starting Qmail and DJBdns so that things would be consistent distribution to distribution.

    I won’t go that far, but I’m using CentOS 8 across the board here so if I go the route of getting everything to work with systemd, everything will work with CentOS 8’s version of systemd. Things may or may not work with Ubuntu or Debian.

    In the meantime, just add duende to the command line given to systemd so that Zoneserver is a sub-process of duende (actually, duende was not there at first and there was a time Zoneserver was just a background job in Bash).

    #78
    maradns
    Keymaster

    Here is MaraDNS’s zoneserver system start up script:

    https://github.com/samboy/MaraDNS/blob/master/build/zoneserver.startup

    #79
    pillarsdotnet
    Participant

    Yes, I’m aware of the existence of traditional SysV startup scripts included with MaraDNS.

    I’m replacing them, in my environment, with systemd service files. I don’t expect you to adopt my custom installation method nor recommend it for all users.

    I just think it notable that /usr/sbin/zoneserver runs fine from the command-line or when launched from /bin/sh or /usr/bin/strace but not when launched directly by systemd.

    I wonder if it looks for some environment variable which systemd does not supply by default?

    I’ll probably dig through the code myself and figure it out; if I do, I may submit a PR on github.

    For now, I’m happy with the following service file:

    [Unit]
    Description=MaraDNS Zoneserver handles DNS zone transfers and any TCP DNS queries
    Documentation=man:zoneserver(8)
    Requires=network.target
    
    [Service]
    ExecStart=/bin/sh -c '/usr/sbin/zoneserver -f /etc/maradns/mararc'
    Restart=always
    
    [Install]
    WantedBy=multi-user.target
    #83
    maradns
    Keymaster

    This is a very interesting bug and I do not know why zoneserver and only zoneserver acts this way. I can tell you this much: zoneserver also is the only service I can not start up in a podman (CentOS 8’s Docker clone); when I try to start up zoneserver in a Podman container, I get a “fork error”.

    Zoneserver uses the fork() model to handle incoming connections. When an incoming connecting comes in via TCP, Zoneserver forks a sub-process to handle the DNS-over-TCP connection. While this is not particularly efficient, it allowed me to fairly quickly get the “has support for TCP” checkbox checked when I was trying to get a fully functional basic DNS server out the door as quickly as possible back when Bind was the only open source DNS server and the Internet community felt having that kind of monoculture was not healthy.

    I have not gotten to the bottom of zoneserver’s issue with systemd or with Podman. I also know that newer versions of Dig have issues with the form of DNS-over-TCP packets sent by MaraDNS (and, I believe, zoneserver), so DNS-over-TCP has been relegated to the back burner: DNS is perfectly usable over just UDP, and DNS-over-TCP just really isn’t used except for zone transfers.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.