On 2023-06-25 23:21 +0100, bl...@debian.org wrote:
> Package: dictd
> Severity: important
> User: bl...@debian.org
> Usertags: missing-systemd-service
>
> Dear Maintainer(s),
>
> dictd has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file. The default init system in
> Debian is systemd, and so far this worked because a transitional
> sysv-init-to-unit generator was shipped by systemd. This is in the
> process of being deprecated and will be removed by the time Trixie
> ships, so the remaining packages that ship init scripts without
> systemd units will stop working.
The other day I checked my system for init scripts without a
corresponding service file, and found dictd as the only package left.
Since dictd supports both running as a daemon and being started on
demand via inetd, I took the effort to translate the latter option into
systemd socket activation[1], adapting the units from the dicod package
which fulfills the same purpose as dictd. The three systemd units I
installed on my system are attached.
In the per-connection instance dictd@.service I have set User=dictd. It
would be possible to do that in dictd.service as well by shipping a
tmpfiles.d(5) snippet that creates a directory (say, /run/dictd)
writable by the dictd user, and changing the PIDFile= option to create
the pid file in that directory rather than directly under /run. Since
dictd drops privileges very early I did not bother to do that, nor did
I implement any of the proposed hardening features[2]. But that is
certainly something the maintainer should consider.
Occasionally I saw the error message
dictd.service: Failed to parse PID from file /run/dictd.pid: Invalid argument
in the logs, which indicates some kind of race condition I do not fully
understand. The service worked fine anyway, but I have chosen to enable
dictd.socket instead on my system since that does not require a
permanently waiting daemon, and the answers from the per-connection
instances were pretty much instantaneous.
How all this fits into the existing scheme where debconf and ucf are
used to let users switch between daemon and on-demand activation, and
how the various README files need to be updated, is unclear to me and
really needs to be decided by the maintainer.
Cheers,
Sven
1. https://0pointer.net/blog/projects/inetd.html
2. https://bugs.debian.org/1032331
[Unit]
Description=Dictd dictionary server daemon
Documentation=man:dictd(8)
After=network.target
[Service]
Type=forking
PIDFile=dictd.pid
EnvironmentFile=-/etc/default/dictd
ExecStart=/usr/sbin/dictd $DICTD_ARGS
[Install]
WantedBy=multi-user.target
[Unit]
Description=Dictd dictionary server socket
Before=dictd.service
Conflicts=dictd.service
[Socket]
ListenStream=2628
Accept=yes
[Install]
WantedBy=sockets.target
[Unit]
Description=Dictd dictionary server per-connection daemon
Documentation=man:dictd(8)
[Service]
EnvironmentFile=-/etc/default/dictd
ExecStart=-/usr/sbin/dictd --inetd $DICTD_ARGS
StandardInput=socket
User=dictd
