Hi Simon, Excerpts from Simon Kelley's message of 2011-09-05 17:35:46 +0200: > The bug which originally prompted the "dnsmasq" user is > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338353 > which may shed more light. Yep, that underlines what I wrote as a comment in the service file.
> My feeling is that the .pid file is there for the use of the systemV > init system, so having no PID file may be an option if dnsmasq is being > controlled by systemd instead. Note that dnsmasq will by default write a > PID file at /var/run/dnsmasq.pid, so this needs to be actively disabled > with --pid-file in this case. Yep, I did that already (did you see the updated service file?). > > 1) Make dnsmasq capable of getting the DNS domain name on its own. It’s not > > too > > much code, I’ve ripped out the appropriate parts of 'hostname', it’s less > > than one page of code, see http://p.nnev.de/2017. Not sure if it becomes > > even less code when using functions which are in your code-base already. > > > > Advantages: You could make that lookup asynchronuous, thus starting > > dnsmasq > > faster (it does not have to wait blockingly on resolving the hostname but > > can immediately show up on DBus). Also, we don’t have to use shell in the > > boot process just for expanding the parameter. > > > > 2) Start /bin/sh -c 'dnsmasq …' in the service file. > > > > Advantages: No code changes to dnsmasq. > > > > I do prefer the first option. What do you think? > > > I think this approaches the problem from the wrong end. Consider this > scenario: user installs dnsmasq and configures it by editing > /etc/dnsmasq.conf, /etc/default/dnsmasq, dropping files in > /etc/dnsmasq.d. Now user installs systemd and expects dnsmasq to be > started by systemd instead of the sysV initscript. The systemd-started > dnsmasq should behave in the same way as before and not arbitrarily > ignore some of the configuration which previously worked. The > dnsdomainname line (and the others) have been in /etc/default/dnsmasq > for a long time, backwards compatibility says it should continue to work > and if it doesn't, the package maintainer (ie, me) will rightly get grief. Well, if we go for option 1, we could deprecate the DOMAIN_SUFFIX variable and have a way that works for sysvinit *and* systemd. Apart from that, I don’t really see a way to still support the DOMAIN_SUFFIX variable without shipping a Debian-specific script that generates a temporary config file. I consider that really ugly, though, for multiple reasons: It’s a shell-script and in the systemd world we like to avoid those. Furthermore, it’s Debian-specific, so other distributions still have the problem of setting the domain suffix. I’ve asked in #systemd and Fedora uses a service file where the user has to manually configure the domain suffix in /etc/sysconfig/dnsmasq. On Arch Linux, the user is supposed to configure it in /etc/dnsmasq.conf. Unrelated to that issue, I’ve learnt that the handling of /etc/default/locale to have LANG is completely unnecessary in systemd. systemd will read /etc/locale.conf and fall back (on Debian) to /etc/default/locale anyways, so all services have correct environment without doing anything specific. I’ve updated the service file accordingly and attached the most recent version. Best regards, Michael
dnsmasq.service
Description: Binary data
