Ignoring SYSTEMD_INSTANCE environment variable

I am using kres inside docker container in which it is installed according to official instructions. In order to avoid issue of stale sockets I decided to force the id with SYSTEMD_INSTANCE environment variable as such in my entrypoint:

SYSTEMD_INSTANCE=1 kresd -n -c /etc/knot-resolver/kresd.conf /run/knot-resolver

Without any success:

$ docker exec -it kres-test ls /run/knot-resolver/control

10

Image is based on ubuntu:20.04 if it does matter somehow.

Can you please describe in more detail what is the issue you have with "stale sockets"?

I'm not aware that SYSTEMD_INSTACE would have any effect on our default docker images - there is no systemd there...

Also, if you're using a custom image/config, please show us the files you're using so we can debug this further

As you can see in /lib/systemd/system/kresd@.service, systemd unit adds another configuration file /usr/lib/knot-resolver/distro-preconfig.lua which does what you're missing. But maybe you'll be better off with explicitly using net.listen inside your config to create control socket at desired location.

Let me be explicit, you can simply

net.listen('/some/path/for/socket', nil, { kind = 'control' })

But overall, we don't have a "packaging for docker", so there are complications. Multiple processes, including garbage collector, and #637 (and maybe others)

After restarting every web interface access ends with error similiar to this:

[net ] map() error while connecting to control socket /run/knot-resolver/control/14: socket:connect: Connection refused (ignoring this socket)

It is known issue #670 (closed), but I think I took necessary preparations in my environment

Firstly Dockerfile:

FROM ubuntu:20.04
LABEL maintainer=lukasz@jarosz.pl

ENV TZ=Europe/Warsaw

RUN apt-get update && apt-get install -y wget cron python3 python3-pip
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
  wget https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb && dpkg -i knot-resolver-release.deb && rm knot-resolver-release.deb \
  && apt-get update && apt-get install -y knot-resolver knot-resolver-module-http

# binaries setup and configuration
ADD files/ /
RUN chmod +x /usr/bin/rpz.py /usr/bin/entrypoint.sh \
  && pip3 install lxml click

# cron setup
COPY crontab.rpz /
RUN crontab -u knot-resolver /crontab.rpz && rm /crontab.rpz

RUN apt-get remove -y python3-pip wget && apt-get autoremove -y

VOLUME /cache
WORKDIR /run/knot-resolver
ENTRYPOINT ["/usr/bin/entrypoint.sh"] 

And my entrypoint.sh (deleting old sockets actually fixes the issue, but kind of like killing pidgeons with nukes):

#!/bin/bash

if [ ! -x /cache/knot-resolver ]; then
  echo "Creating cache directory"
  mkdir /cache/knot-resolver
  chown knot-resolver:knot-resolver /cache/knot-resolver
fi

if [ -x /run/knot-resolver/control ]; then
  echo "Deleting old sockets"
  rm -f /run/knot-resolver/control/*
fi

echo "Starting cron"
cron -L 0
echo "Starting kresd"
SYSTEMD_INSTANCE=1 kresd -n -c /etc/knot-resolver/kresd.conf /run/knot-resolver

I don't think kresd.conf is relevant here, but I attach it anyways:

-- modules
modules = {
  'policy',
  'view',

  'workarounds < iterate',
  'stats', -- required by predict module
  'predict',
  'http',
}

log_target('stdout')

-- network
net.ipv6 = false
net.listen('0.0.0.0', 53, { kind = 'dns' })
net.listen('0.0.0.0', 8453, { kind = 'webmgmt' })

-- permissions
user('knot-resolver','knot-resolver')

-- cache, stats, performance optimizations
cache.open(950*MB, 'lmdb:///cache/knot-resolver')
-- cache.min_ttl(600)

predict.config({
    window = 5,
    period = 1*(60/5)
  })

trust_anchors.remove('.')

-- limit access with ACLs
view:addr('127.0.0.0/8', policy.all(policy.PASS))
view:addr('172.16.0.0/12', policy.all(policy.PASS))
view:addr('10.0.0.0/8', policy.all(policy.PASS))

view:addr('0.0.0.0/0', policy.all(policy.DROP))

-- query resolving policies
policy.add(policy.rpz(policy.ANSWER, '/run/knot-resolver/blacklist.rpz', true))
policy.add(policy.all(policy.FORWARD({
  "9.9.9.9",
  "8.8.8.8",
  }))) -- catch all and send to quad9 then quad8

I don't know if this is related but when put under load (around 30-50% of my AS capacity) after about 36h resolvers firstly stopped responding for prometheus queries then they started dropping queries.

I recommend against the predict.config part; it can cause issues. See !1273 (fb7d5e6c)

I think it is very necessary change, because I understood "prototype" as stable (since it is stable branch), but can offer little to no benefit.

Everything here has been addressed, I think. If not, maybe it would better get reformulated in a new issue anyway.

closed