[Dnsmasq-discuss] [dnsmasq-devel] [PATCH] support systemd socket activation

Simon Kelley simon at thekelleys.org.uk
Thu May 19 11:43:41 BST 2011


microcai wrote:
> Heya,
> 
> Can't find the public repo from the project web page. SO no idea if you
> guys have did that.

No public repo, sending patches here is good.

> 
> Here is my patch to support systemd socket activation, and 2 unit files
> for systemd.

Ok, I'm a systemd newbie, but I have a few questions.

Why use systemd to open the port 53 sockets but not the DHCP and TTFTP ones?

from the systemd "daemon" manpage, these seem to be relevant, but I
don't think they're done in this patch:


#

If possible and applicable expose the daemon's control interface via the
D-Bus IPC system and grab a bus name as last step of initialization.
#

For integration in systemd, provide a .service unit file that carries
information about starting, stopping and otherwise maintaining the
daemon. See systemd.service(5) for details.
#

As much as possible, rely on the init systemd's functionality to limit
the access of the daemon to files, services and other resources. i.e. in
the case of systemd, rely on systemd's resource limit control instead of
implementing your own, rely on systemd's privilege dropping code instead
of implementing it in the daemon, and similar. See systemd.exec(5) for
the available controls.
#

If D-Bus is used, make your daemon bus-activatable, via supplying a
D-Bus service activation configuration file. This has multiple
advantages: your daemon may be started lazily on-demand; it may be
started in parallel to other daemons requiring it -- which maximizes
parallelization and boot-up speed; your daemon can be restarted on
failure, without losing any bus requests, as the bus queues requests for
activatable services. See below for details.
#

#

If applicable a daemon should notify the init system about startup
completion or status updates via the sd_notify(3) interface.
#

Instead of using the syslog() call to log directly to the system logger,
a new-style daemon may choose to simply log to STDERR via fprintf(),
which is then forwarded to syslog by the init system. If log priorities
are necessary these can be encoded by prefixing individual log lines
with strings like "<4>" (for log priority 4 "WARNING" in the syslog
priority scheme), following a similar style as the Linux kernel's
printk() priority system. In fact, using this style of logging also
enables the init system to optionally direct all application logging to
the kernel log buffer (kmsg), as accessible via dmesg(1). This kind of
logging may be enabled by setting StandardError=syslog in the service
unit file. For details see sd-daemon(7) and systemd.exec(5).


Note that dnsmasq has quite a lot of DBus infrastructure already in
  place.



Cheers,

Simon.



More information about the Dnsmasq-discuss mailing list