Skip to main content ↑ ↓
Topic: technitium-dns service (Read 213 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

technitium-dns service

Hello,

A total noob here, but I'm trying  ;)

I noticed that the technitium-dns AUR package does not have a dinit service definition and I tried to create one myself.
I have an up-to-date Artix installed from the latest image a few days ago.
dinit is version 0.18.0-5

Here is my current iteration:
/etc/dinit.d/technitium-dns
Code: [Select]
type            = process
command         = /usr/bin/dotnet /opt/technitium-dns-server/DnsServerApp.dll
working-dir     = /opt/technitium-dns-server
run-as          = technitium
restart         = true
smooth-recovery = true
log-type        = buffer
waits-for       = network.target
depends-on      = technitium-dns-pre

/etc/dinit.d/technitium-dns-pre
Code: [Select]
type         = scripted
command      = /usr/bin/setcap 'cap_net_bind_service,cap_net_raw,cap_net_admin=+ep' /opt/technitium-dns-server/DnsServerApp.dll
restart      = false
after        = local.target

Yesterday I managed to start the service.
Today it refuses:
Code: [Select]
# dinitctl start technitium-dns
Service 'technitium-dns' failed to start.
Reason: a dependency of the service failed to start. Check dinit log.

I cannot find the dinit log - I checked all the /var/log/dinit/*.log files ...

Does this ring a bell to anyone ?

Thank you in advance for your inputs !

Re: technitium-dns service

Reply #1 –
Are you sure the commands execute successfully under the environment described in the service file? Also you can try with mono instead of MS .net runtime if it works.

Re: technitium-dns service

Reply #2 –
Quote
Code: [Select]
command      = /usr/bin/setcap 'cap_net_bind_service,cap_net_raw,cap_net_admin=+ep' /opt/technitium-dns-server/DnsServerApp.dll

Note that those single quotes are meaningless to Dinit (and so will be passed through to setcap, which probably doesn't expect to see them) - use double quotes or remove them altogether.

Re: technitium-dns service

Reply #3 –
Hello,

Thank you for your inputs !

To answer questions in order:
  • the commands are legit; if I run in the terminal (Konsole) the command line to start the service, the process will start and behave normally, no need to fiddle with Mono.
    Code: [Select]
    # /usr/bin/dotnet /opt/technitium-dns-server/DnsServerApp.dll
    Technitium DNS Server was started successfully.
    Using config folder: /opt/technitium-dns-server/config

    Note: Open http://myserver:5380/ in web browser to access web console.

    Press [CTRL + C] to stop...
    ^C
    Technitium DNS Server is stopping...
    Technitium DNS Server was stopped successfully.
  • As suggested, I first replaced the simple quotes with double quotes in /etc/dinit.d/technitium-dns-pre - it did not have any influence at all; then I removed them entirely, to have the same result
    Code: [Select]
    # dinitctl start technitium-dns-pre 
    Service 'technitium-dns-pre' failed to start.
    Reason: service process terminated before ready: exited - status 1
    Now it looks like this
    Code: [Select]
    type         = scripted
    command      = /usr/bin/setcap cap_net_bind_service,cap_net_raw,cap_net_admin=+ep /opt/technitium-dns-server/DnsServerApp.dll
    restart      = false
    after        = local.target

Is there a way to audit the execution of the pre script and of its counterpart ?

dinitcheck says everything looks OK:

Code: [Select]
# dinitcheck technitium-dns
Checking service: technitium-dns...
Checking service: network.target...
Checking service: technitium-dns-pre...
Checking service: pre-network.target...
Checking service: local.target...
Checking service: pre-local.target...
Checking service: tmpfiles-setup...
Checking service: sysusers...
Checking service: early-fs-local.target...
Checking service: early-console.target...
Checking service: net-lo...
Checking service: hostname...
Checking service: swap...
Checking service: random-seed...
Checking service: sysctl...
Checking service: binfmt...
Checking service: hwclock...
Checking service: locale...
Checking service: early-root-rw.target...
Checking service: early-fs-pre.target...
Checking service: early-fs-fstab.target...
Checking service: early-devices.target...
Checking service: early-keyboard.target...
Checking service: early-modules.target...
Checking service: udevd-early...
Checking service: early-prepare.target...
Checking service: fsck-root...
Checking service: fsck...
Checking service: udev-settle...
Checking service: modules...
Checking service: kmod-static-nodes...
Checking service: tmpfiles-dev...
Checking service: root-ro...
Checking service: pseudofs...
Checking service: cgroups...
Checking service: tmpfs...
Checking service: udev-trigger...
Performing secondary checks...
Secondary checks complete.
No problems found.

Code: [Select]
# dinitcheck technitium-dns-pre 
Checking service: technitium-dns-pre...
Checking service: local.target...
Checking service: pre-local.target...
Checking service: tmpfiles-setup...
Checking service: sysusers...
Checking service: early-fs-local.target...
Checking service: early-console.target...
Checking service: net-lo...
Checking service: hostname...
Checking service: swap...
Checking service: random-seed...
Checking service: sysctl...
Checking service: binfmt...
Checking service: hwclock...
Checking service: locale...
Checking service: early-root-rw.target...
Checking service: early-fs-pre.target...
Checking service: early-fs-fstab.target...
Checking service: early-devices.target...
Checking service: early-keyboard.target...
Checking service: early-modules.target...
Checking service: udevd-early...
Checking service: early-prepare.target...
Checking service: fsck-root...
Checking service: fsck...
Checking service: udev-settle...
Checking service: modules...
Checking service: kmod-static-nodes...
Checking service: tmpfiles-dev...
Checking service: root-ro...
Checking service: pseudofs...
Checking service: cgroups...
Checking service: tmpfs...
Checking service: udev-trigger...
Performing secondary checks...
Secondary checks complete.
No problems found.

Also, why does dinit suggests to look into the "dinit log" if there is nothing written there ?
Can I make it more "verbose" ?

Again, thanks for your feedback !

Re: technitium-dns service

Reply #4 –
Quote
I cannot find the dinit log - I checked all the /var/log/dinit/*.log files ...
Quote
Also, why does dinit suggests to look into the "dinit log" if there is nothing written there ?

/var/log/dinit/*.log is used by Artix to keep log files for various services when running under Dinit.

Dinit itself logs to the system log, i.e. where the messages end up is dependent on the system log daemon that is active. For example, if you have syslog-ng installed and running, and have it properly configured, then you might see log messages in /var/log/daemon.log file.

However, it seems there are two problems with Artix configuration that currently prevent that from working properly:

  • First, the log daemon (eg syslog-ng) is configured as a "process" service which doesn't use startup notification. This is problematic because dinit tries to open the log as soon as the process is launched, but the log won't be available until after the service has actually set it up. I might try to implement a workaround for this in dinit itself at some point, however, in the case of syslog-ng, I was able to resolve it by editing the /etc/dinit.d/syslog-ng service file so that it contained:

    Code: [Select]
    #type            = process
    type            = bgprocess
    #command         = /usr/bin/syslog-ng -F
    command         = /usr/bin/syslog-ng -p /var/run/syslog-ng.pid --process-mode=background
    #added:
    pid-file        = /var/run/syslog-ng.pid
    smooth-recovery = true
    options         = starts-log
    depends-on      = pre-local.target
    before          = login.target

    (I've kept the original lines commented out, so that you can see the changes necessary).
  • Secondly, the default configuration for syslog-ng in /etc/syslog-ng/syslog-ng.conf is set to log basically nothing (the log destinations are commented out). I fixed that by uncommenting the filter and destination for daemon logging, i.e:

    Code: [Select]
    log {
            source(s_local);
            filter(f_daemon);
            destination(d_daemon);
    };

If you fix those issues, or any equivalent problems with whatever logging daemon you're actually using, then you should see failure status being reported by dinit in the system log.

Other than that, the best bet for diagnosing failures for individual services is to check the logs for the services themselves. Since your main service has log-type        = buffer you can use dinit catlog technitium-dns to see anything that it produced. Your "pre" services doesn't have any log configured so you won't be able to see its output (you could change it to also use "log-type = buffer", for example, to get around that).

(Edit: turns out you want "--proces-mode=background" in the syslog-ng command line also for optimal use under dinit).

Re: technitium-dns service

Reply #5 –
Thank you very much for the thorough explanations !

I learned a lot from your last post; I did not setup anything in particular for logging, believing that the system is sufficiently configured for collecting the logs.
First, I went on and configured syslog-ng as you recommended and I have now a richer source of information.

Second, I better understood the limitations of the technitium-dns application itself:
  • in order to bind to the port 53, it must have special rights to do so
  • although when installed form the AUR package a correct user and group (technitium) are created, binding to port 53 is not allowed
  • the solution was, as I thought initially, to attribute the system capabilities to the binary itself (hence the pre script); it turns out that it is not the DLL file that has to receive them, but the /usr/bin/dotnet process that will load the DLL , so it is too much power given to it - not so good; also there is an article on unix.stackexchange.com where the advantages and pitfalls of setcap are discussed
  • on GitHub there is an open issue #887 about the need to run technitium-dns as root and it became clear that the easier way forward is to do so, for now
  • I changed the dinit service file definition to take into account all this and now the service starts and behaves normally
    /etc/dinit.d/technitium-dns looks like this now
    Code: [Select]
    type            = process
    command         = /usr/bin/dotnet /opt/technitium-dns-server/DnsServerApp.dll
    working-dir     = /opt/technitium-dns-server
    restart         = true
    smooth-recovery = true
    log-type        = buffer
    waits-for       = network.target
  • there is no longer a need for a pre script

My purpose was to have the technitium-dns service declared and working in my dinit based Artix, so it is a 100% success.
I learned a few things and I have better logging now.

I'm grateful for the help and knowledge provided and I would like to contribute something in return.

The last question I have is "How can I submit the service definition to the main repository of Artix ?" in case it proves to be useful for others ?