Bug#640095: systemd configuration fails to start dnsmasq
Yep, I did that already (did you see the updated service file?). Not when I wrote my last message, but I have now. It's much better, thank you. 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. I would be inclined to just state that the whole of /etc/default/dnsmasq is not used when systemd is in use except that we haven't yet addressed resolvconf. It seems to me that the wrapper script is the only way to solve that problem, too, so maybe it's worth biting the bullet and doing it. Yes, it's a bit nasty, but it makes it very easy to retain complete backwards compatibility in the Debian package. That really is valuable - it's one of Debian's USPs that upgrades Just Work. I'm happy to distribute a service file without the Debian elaborations too, in fact I already do: /contrib/systemd/dnsmasq.service v. debian/systemd.service resolvconf is an issue. Not supporting it will break far more systems than DOMAIN_SUFFIX. 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. That's good. I'll think about how to do a wrapper and get back to you. Cheers, Simon. Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640095: systemd configuration fails to start dnsmasq
Hi Simon, Excerpts from Michael Stapelberg's message of 2011-09-02 17:15:23 +0200: Simon, what do you think? Is running dnsmasq as user dnsmasq by default a sensible decision? Yes, it is. Alright, I will change the service file to do that. So, I reflected about this, and we cannot use User=dnsmasq in the service file because dnsmasq needs to bind to port 53 as root. But aside from that, I wonder why we (as in: Debian) need to use the dnsmasq user while the default is the 'nobody' user, which we also have in Debian. The only difference I can spot so far is that the dnsmasq user has /var/lib/misc as homedir and dnsmasq stores a file called dnsmasq.leases there. I’m not sure what the intentions are, but my first question is: why is that file not in /var/run (and therefore on tmpfs)? • LANG gets set if it is defined in /etc/default/locale. I’m not sure what the effects of that are (I don’t set LANG on my system, I prefer the LC_* settings). Does it somehow affect the behaviour of dnsmasq when resolving? If so, how? It affects the charset used when reading internationalised domain names from configuration files and the translation used for messages. It's needed. OK. I think this could be done with EnvironmentFile=-/etc/default/locale. I will test it and add it (including a comment on why it is necessary). I am still not quite sure about why we need it and what the effects really are. Of course, log messages appear in a different language after setting LANG. But what exactly is the behaviour when resolving? Why does the LANG setting of my *server* define which answers my clients get? The problem I see with using LANG is that /etc/default/locale is Debian-specific and we want to have the same systemd service file for all distributions (ideally). 1) set the domain to the system value An important setting, but should be done via /etc/dnsmasq.conf when using systemd. 2) use a different configuration file. I don’t really see a good reason for that right now, but people who want to do that should just copy /lib/systemd/system/dnsmasq.service to /etc/systemd/system/dnsmasq.service and change it appropriately. 3) set a couple of options which are needed by the Debian installation, without requiring the user to have them in the configuration file. These are the dnsmasq user, and the CONFIG_DIR value. So, this is a Debian-specific option which we really need :-/. I guess we have no other option than shipping two files with dnsmasq or keeping a Debian-specific one in the Debian packaging (the latter sounds better). Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640095: systemd configuration fails to start dnsmasq
Michael Stapelberg wrote: So, I reflected about this, and we cannot use User=dnsmasq in the service file because dnsmasq needs to bind to port 53 as root. Dnsmasq needs to be started as root, but it needs the command-line argument --user=dnsmasq, to tell it to change to user dnsmasq _after binding port 53, etc etc. The reason for this is security: dnsmasq is handling untrusted network data and is theoretically vulnerable to compromise by buffer overflow etc. If it happens, much better that an attacker has control of a process _not_ running as root. nobody is used in the source because that's a non-root, non-real-person user that's available everywhere and will therefore work for source installs. For Debian, we make a user just for this, since a user that has no writable files, no shell, no home dir and is not used for anything else is more secure again. It would be possible to patch the source s/nobody/dnsmasq/ but it's easier to do this in the startup script than maintain the patch. But aside from that, I wonder why we (as in: Debian) need to use the dnsmasq user while the default is the 'nobody' user, which we also have in Debian. The only difference I can spot so far is that the dnsmasq user has /var/lib/misc as homedir and dnsmasq stores a file called dnsmasq.leases there. I’m not sure what the intentions are, but my first question is: why is that file not in /var/run (and therefore on tmpfs)? /var/lib/misc/dnsmasq.leases is the persistent DHCP lease database, it has to survive over reboot. It's also opened whilst dnsmasq is still root, so isn't owned by user dnsmasq. The only file that's owned by dnsmasq is the directory /var/run/dnsmasq. That's done so that the PID file /var/run/dnsmasq/dnsmasq.pid can be deleted by dnsmasq as it exits, even though dnsmasq isn't running as root then. That location for the PID file isn't the standard one either, so gets overridden on the command line. The options which are needed on the command line for debian are therefore -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new (the last one activates the /etc/dnsmasq.d drop-dir for config fragments.) Possibly the solution is something like ExecStart=/usr/sbin/dnsmasq -k -x /var/run/dnsmasq/dnsmasq.pid \ -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new but somehow maintaing the ability to override the config-dir in /etc/default/dnsmasq • LANG gets set if it is defined in /etc/default/locale. I’m not sure what the effects of that are (I don’t set LANG on my system, I prefer the LC_* settings). Does it somehow affect the behaviour of dnsmasq when resolving? If so, how? It affects the charset used when reading internationalised domain names from configuration files and the translation used for messages. It's needed. OK. I think this could be done with EnvironmentFile=-/etc/default/locale. I will test it and add it (including a comment on why it is necessary). I am still not quite sure about why we need it and what the effects really are. Of course, log messages appear in a different language after setting LANG. But what exactly is the behaviour when resolving? Why does the LANG setting of my *server* define which answers my clients get? It doesn't, it tells dnsmasq what character encoding to expect for internationalised domain name strings which appear in configuration files on the _server_. By the time they get over the network they've been transformed into a network-neutral representation. The problem I see with using LANG is that /etc/default/locale is Debian-specific and we want to have the same systemd service file for all distributions (ideally). Same service file for all distros is unlikely to be possible, I think, given the above. 1) set the domain to the system value An important setting, but should be done via /etc/dnsmasq.conf when using systemd. It can't be set to the current system domain name that way DOMAIN_SUFFIX=`dnsdomainname` 2) use a different configuration file. I don’t really see a good reason for that right now, but people who want to do that should just copy /lib/systemd/system/dnsmasq.service to /etc/systemd/system/dnsmasq.service and change it appropriately. 3) set a couple of options which are needed by the Debian installation, without requiring the user to have them in the configuration file. These are the dnsmasq user, and the CONFIG_DIR value. So, this is a Debian-specific option which we really need :-/. I guess we have no other option than shipping two files with dnsmasq or keeping a Debian-specific one in the Debian packaging (the latter sounds better). See above, I'm answering this one point at a time :-) If possible, I'd like to maintain the functionality of /etc/default /dnsmasq for the options documented in there, with the possible expection of the resolvconf one: I guess we still have to fight the resolvconf battles. Cheers, Simon. -- To
Bug#640095: systemd configuration fails to start dnsmasq
Hi Simon, Thanks for your explanations :). My answers follow, a new service file is attached. Excerpts from Simon Kelley's message of 2011-09-05 14:39:42 +0200: Dnsmasq needs to be started as root, but it needs the command-line argument --user=dnsmasq, to tell it to change to user dnsmasq _after binding port 53, etc etc. Yep. The reason for this is security: dnsmasq is handling untrusted network data and is theoretically vulnerable to compromise by buffer overflow etc. If it happens, much better that an attacker has control of a process _not_ running as root. nobody is used in the source because that's a non-root, non-real-person user that's available everywhere and will therefore work for source installs. For Debian, we make a user just for this, since a user that has no writable files, no shell, no home dir and is not used for anything else is more secure again. It would be possible to patch the source s/nobody/dnsmasq/ but it's easier to do this in the startup script than maintain the patch. You are partly right, partly wrong. Partly wrong because: 1) nobody has no files at all (find / -uid 65534 brings no results on my system, also see for example bug #618474 where creation of files owned by nobody is a serious policy violation) 2) nobody has no homedir (while 'dnsmasq' has one!) But partly right because: 3) Indeed, nobody has a shell. 4) With is not used for anything else I guess you mean that nobody potentially runs/controls processes. Therefore, I have added an appropriate comment to the systemd service file and added the --user dnsmasq option :). /var/lib/misc/dnsmasq.leases is the persistent DHCP lease database, it has to survive over reboot. It's also opened whilst dnsmasq is still root, so isn't owned by user dnsmasq. Ah, you are right, it’s owned by root, my mistake. The only file that's owned by dnsmasq is the directory /var/run/dnsmasq. That's done so that the PID file /var/run/dnsmasq/dnsmasq.pid can be deleted by dnsmasq as it exits, even though dnsmasq isn't running as root then. That location for the PID file isn't the standard one either, so gets overridden on the command line. Well, we don’t need a PID file when using systemd. In sysvinit it’s mainly used for locking and sending signals. systemd supports $MAINPID in the ExecReload= command, so we don’t need it for sending signals. Since systemd also knows best if a service still lives or not, we don’t need it for that purpose either. If a program *really* needs to get the PID, it can easily do that using: systemctl show -p MainPID dnsmasq.service I am still not quite sure about why we need it and what the effects really are. Of course, log messages appear in a different language after setting LANG. But what exactly is the behaviour when resolving? Why does the LANG setting of my *server* define which answers my clients get? It doesn't, it tells dnsmasq what character encoding to expect for internationalised domain name strings which appear in configuration files on the _server_. By the time they get over the network they've been transformed into a network-neutral representation. I see. I’ve added an appropriate comment and now read /etc/default/locale in the service file. Same service file for all distros is unlikely to be possible, I think, given the above. Yeah :-(. Too bad, but well, maybe it works for other services. It can't be set to the current system domain name that way DOMAIN_SUFFIX=`dnsdomainname` Hrm, that’s correct. Is that really relevant? For systems where the domain often changes, dnsmasq is probably started by NetworkManager anyways. On other systems, it’s not too much effort to put the domain name in /etc/dnsmasq.conf. If you insist, we have two possibilities: 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? Best regards, Michael dnsmasq.service Description: Binary data
Bug#640095: systemd configuration fails to start dnsmasq
Michael Stapelberg wrote: Hi Simon, Thanks for your explanations :). My answers follow, a new service file is attached. Excerpts from Simon Kelley's message of 2011-09-05 14:39:42 +0200: Dnsmasq needs to be started as root, but it needs the command-line argument --user=dnsmasq, to tell it to change to user dnsmasq _after binding port 53, etc etc. Yep. The reason for this is security: dnsmasq is handling untrusted network data and is theoretically vulnerable to compromise by buffer overflow etc. If it happens, much better that an attacker has control of a process _not_ running as root. nobody is used in the source because that's a non-root, non-real-person user that's available everywhere and will therefore work for source installs. For Debian, we make a user just for this, since a user that has no writable files, no shell, no home dir and is not used for anything else is more secure again. It would be possible to patch the source s/nobody/dnsmasq/ but it's easier to do this in the startup script than maintain the patch. You are partly right, partly wrong. Partly wrong because: 1) nobody has no files at all (find / -uid 65534 brings no results on my system, also see for example bug #618474 where creation of files owned by nobody is a serious policy violation) 2) nobody has no homedir (while 'dnsmasq' has one!) But partly right because: 3) Indeed, nobody has a shell. 4) With is not used for anything else I guess you mean that nobody potentially runs/controls processes. The bug which originally prompted the dnsmasq user is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338353 which may shed more light. Therefore, I have added an appropriate comment to the systemd service file and added the --user dnsmasq option :). /var/lib/misc/dnsmasq.leases is the persistent DHCP lease database, it has to survive over reboot. It's also opened whilst dnsmasq is still root, so isn't owned by user dnsmasq. Ah, you are right, it’s owned by root, my mistake. The only file that's owned by dnsmasq is the directory /var/run/dnsmasq. That's done so that the PID file /var/run/dnsmasq/dnsmasq.pid can be deleted by dnsmasq as it exits, even though dnsmasq isn't running as root then. That location for the PID file isn't the standard one either, so gets overridden on the command line. Well, we don’t need a PID file when using systemd. In sysvinit it’s mainly used for locking and sending signals. systemd supports $MAINPID in the ExecReload= command, so we don’t need it for sending signals. Since systemd also knows best if a service still lives or not, we don’t need it for that purpose either. If a program *really* needs to get the PID, it can easily do that using: systemctl show -p MainPID dnsmasq.service 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. I am still not quite sure about why we need it and what the effects really are. Of course, log messages appear in a different language after setting LANG. But what exactly is the behaviour when resolving? Why does the LANG setting of my *server* define which answers my clients get? It doesn't, it tells dnsmasq what character encoding to expect for internationalised domain name strings which appear in configuration files on the _server_. By the time they get over the network they've been transformed into a network-neutral representation. I see. I’ve added an appropriate comment and now read /etc/default/locale in the service file. Same service file for all distros is unlikely to be possible, I think, given the above. Yeah :-(. Too bad, but well, maybe it works for other services. It can't be set to the current system domain name that way DOMAIN_SUFFIX=`dnsdomainname` Hrm, that’s correct. Is that really relevant? For systems where the domain often changes, dnsmasq is probably started by NetworkManager anyways. On other systems, it’s not too much effort to put the domain name in /etc/dnsmasq.conf. If you insist, we have two possibilities: 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
Bug#640095: systemd configuration fails to start dnsmasq
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
Bug#640095: systemd configuration fails to start dnsmasq
On Fri, 2011-09-02 at 16:04 +0100, Simon Kelley wrote: Michael Stapelberg wrote: Hi Sjoerd, When using systemd starting dnsmasq just hangs and times out.. Also the sysv init script seems to have a reasonable amount of functionality that the systemd one does not have, so i'm not sure if switching now is the right thing.. Which version of systemd do you use? I tested the service file with systemd 29 Latest in debian, so 29 and it works just fine: michael ~ $ sudo systemctl start dnsmasq.service michael ~ $ systemctl status dnsmasq.service dnsmasq.service - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service) Active: active (running) since Fri, 02 Sep 2011 16:25:45 +0200; 700ms ago Process: 28971 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS) Main PID: 28973 (dnsmasq) CGroup: name=systemd:/system/dnsmasq.service └ 28973 /usr/sbin/dnsmasq -k Can you please do the following? 1) Run strace -o /tmp/strace.log -fF -tt -s2048 -p 1 2) Run systemctl start dnsmasq.service 3) Attach the (bzip2'ed) contents of /tmp/strace.log Sure attached. Looks like you're using a dbus service, while by default (afaik) dnsmasq isn't configured to connect to dbus, so it'll just wait forever and ever.. • The resolvconf stuff I regard as obsolete when using NetworkManager or some other configuration tool. Hmm, I'm not going to argue that one ;-) As long as you ensure NM still correctly interacts with dnsmasq such that all local nameserver queries can go via dnsmasq and dnsmasq uses the resolv.conf file written by NM this might be true. There are other cases where resolvconf is useful though (essential every time you get dns servers from multiple services).. I'm not sure that just taking the stanza that resolvconf is useless is a useful one at this point... -- Sjoerd Simons sjo...@luon.net strace.log.bz2 Description: application/bzip
Bug#640095: systemd configuration fails to start dnsmasq
Hi Sjoerd, Excerpts from Sjoerd Simons's message of 2011-09-03 14:53:27 +0200: Sure attached. Looks like you're using a dbus service, while by default (afaik) dnsmasq isn't configured to connect to dbus, so it'll just wait forever and ever.. Ah, yes, indeed. Sorry, I completely missed that this is not the default in the dnsmasq config :). DBus activation makes sense because it’s the best way for systemd to know when the service has actually started. I will update the service file with all the points we have discussed in this bug report soon. In the meantime, can you please try using the following line? ExecStart=/usr/sbin/dnsmasq -k --enable-dbus That should make it start correctly. As long as you ensure NM still correctly interacts with dnsmasq such that all local nameserver queries can go via dnsmasq and dnsmasq uses the resolv.conf file written by NM this might be true. NetworkManager can use dnsmasq for this purpose, just put dns=dnsmasq in the [main] section of /etc/NetworkManager/NetworkManager.conf Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640095: systemd configuration fails to start dnsmasq
Package: dnsmasq Version: 2.58-2 Severity: important When using systemd starting dnsmasq just hangs and times out.. Also the sysv init script seems to have a reasonable amount of functionality that the systemd one does not have, so i'm not sure if switching now is the right thing. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dnsmasq depends on: ii adduser 3.113 ii dnsmasq-base 2.58-2 ii netbase 4.46 dnsmasq recommends no packages. Versions of packages dnsmasq suggests: ii resolvconf 1.59 -- Configuration Files: /etc/dnsmasq.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640095: systemd configuration fails to start dnsmasq
Hi Sjoerd, When using systemd starting dnsmasq just hangs and times out.. Also the sysv init script seems to have a reasonable amount of functionality that the systemd one does not have, so i'm not sure if switching now is the right thing. Which version of systemd do you use? I tested the service file with systemd 29 and it works just fine: michael ~ $ sudo systemctl start dnsmasq.service michael ~ $ systemctl status dnsmasq.service dnsmasq.service - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service) Active: active (running) since Fri, 02 Sep 2011 16:25:45 +0200; 700ms ago Process: 28971 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS) Main PID: 28973 (dnsmasq) CGroup: name=systemd:/system/dnsmasq.service └ 28973 /usr/sbin/dnsmasq -k Can you please do the following? 1) Run strace -o /tmp/strace.log -fF -tt -s2048 -p 1 2) Run systemctl start dnsmasq.service 3) Attach the (bzip2'ed) contents of /tmp/strace.log That will allow us to better see what’s going on. As for the functionality: • The init script provides support for the ENABLED flag in /etc/default/dnsmasq, which you don’t need when using systemd -- systemd supports enable/disable: systemctl disable dnsmasq.service • It runs dnsmasq as user 'dnsmasq' - I missed this one and we can easily add it to the service file (User=dnsmasq in the [Service] section). Simon, what do you think? Is running dnsmasq as user dnsmasq by default a sensible decision? • The resolvconf stuff I regard as obsolete when using NetworkManager or some other configuration tool. • LANG gets set if it is defined in /etc/default/locale. I’m not sure what the effects of that are (I don’t set LANG on my system, I prefer the LC_* settings). Does it somehow affect the behaviour of dnsmasq when resolving? If so, how? • As for configuration via flags (all these environment variables): In general, the systemd way is to configure programs in their own configuration files, so /etc/dnsmasq.conf is the place where all this should be configured. Simon: Are there any options which are *only* available via command line and *not* in /etc/dnsmasq.conf that are reasonable for users to change? If so, which ones? Did I miss any functionality? Thanks for your bugreport, and hopefully we can improve the service file :). Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640095: systemd configuration fails to start dnsmasq
Hi Simon, Thanks for your reply. Excerpts from Simon Kelley's message of 2011-09-02 17:04:54 +0200: • It runs dnsmasq as user 'dnsmasq' - I missed this one and we can easily add it to the service file (User=dnsmasq in the [Service] section). Simon, what do you think? Is running dnsmasq as user dnsmasq by default a sensible decision? Yes, it is. Alright, I will change the service file to do that. • LANG gets set if it is defined in /etc/default/locale. I’m not sure what the effects of that are (I don’t set LANG on my system, I prefer the LC_* settings). Does it somehow affect the behaviour of dnsmasq when resolving? If so, how? It affects the charset used when reading internationalised domain names from configuration files and the translation used for messages. It's needed. OK. I think this could be done with EnvironmentFile=-/etc/default/locale. I will test it and add it (including a comment on why it is necessary). There are none which can't be changed from the configuration file, and most of the environment variables are indeed obsolete: The non-obsolete ones are documented in the /etc/default/dnsmasq file. 1) set the domain to the system value 2) use a different configuration file. 3) set a couple of options which are needed by the Debian installation, without requiring the user to have them in the configuration file. These are the dnsmasq user, and the CONFIG_DIR value. Will look at those tomorrow, got to go now. The initscript sleeps for a couple of seconds between stopping and then starting the daemon on a restart. That is necessary. You consider that functionality? It sounds wrong. Why exactly is it necessary? :) Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640095: systemd configuration fails to start dnsmasq
Michael Stapelberg wrote: Hi Sjoerd, When using systemd starting dnsmasq just hangs and times out.. Also the sysv init script seems to have a reasonable amount of functionality that the systemd one does not have, so i'm not sure if switching now is the right thing. Which version of systemd do you use? I tested the service file with systemd 29 and it works just fine: michael ~ $ sudo systemctl start dnsmasq.service michael ~ $ systemctl status dnsmasq.service dnsmasq.service - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service) Active: active (running) since Fri, 02 Sep 2011 16:25:45 +0200; 700ms ago Process: 28971 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS) Main PID: 28973 (dnsmasq) CGroup: name=systemd:/system/dnsmasq.service └ 28973 /usr/sbin/dnsmasq -k Can you please do the following? 1) Run strace -o /tmp/strace.log -fF -tt -s2048 -p 1 2) Run systemctl start dnsmasq.service 3) Attach the (bzip2'ed) contents of /tmp/strace.log That will allow us to better see what’s going on. As for the functionality: • The init script provides support for the ENABLED flag in /etc/default/dnsmasq, which you don’t need when using systemd -- systemd supports enable/disable: systemctl disable dnsmasq.service • It runs dnsmasq as user 'dnsmasq' - I missed this one and we can easily add it to the service file (User=dnsmasq in the [Service] section). Simon, what do you think? Is running dnsmasq as user dnsmasq by default a sensible decision? Yes, it is. • The resolvconf stuff I regard as obsolete when using NetworkManager or some other configuration tool. Hmm, I'm not going to argue that one ;-) • LANG gets set if it is defined in /etc/default/locale. I’m not sure what the effects of that are (I don’t set LANG on my system, I prefer the LC_* settings). Does it somehow affect the behaviour of dnsmasq when resolving? If so, how? It affects the charset used when reading internationalised domain names from configuration files and the translation used for messages. It's needed. • As for configuration via flags (all these environment variables): In general, the systemd way is to configure programs in their own configuration files, so /etc/dnsmasq.conf is the place where all this should be configured. Simon: Are there any options which are *only* available via command line and *not* in /etc/dnsmasq.conf that are reasonable for users to change? If so, which ones? There are none which can't be changed from the configuration file, and most of the environment variables are indeed obsolete: The non-obsolete ones are documented in the /etc/default/dnsmasq file. 1) set the domain to the system value 2) use a different configuration file. 3) set a couple of options which are needed by the Debian installation, without requiring the user to have them in the configuration file. These are the dnsmasq user, and the CONFIG_DIR value. 4) ENABLED and IGNORE_REOLVCONF, which would seem to be not relevant in a systemd world. Did I miss any functionality? The initscript sleeps for a couple of seconds between stopping and then starting the daemon on a restart. That is necessary. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
