Description of problem: The init script for dnsmasq is not aware of the possibility to have several dnsmasq processes on the same system. Now, you have for example libvirt installed with its dnsmasq embedded processes and you also want to use dnsmasq inside the OS, you cannot easily manage this. For example if you have cobbler server on the same system where you have libvirt configured (qemu/KVM host with several networks), each time you issue the command "cobbler sync" you get all the dnsmasq processes killed and then only the OS one restarted... And also, to restart libvirtd embedded dnsmasq processes is very difficult (it seems service libvirtd restart doesn't make it...) Version-Release number of selected component (if applicable): dnsmasq-2.46-2.fc11.x86_64 How reproducible: always Steps to Reproduce: 1. install and configure libvirt and some virtual networks with virt-manager tool 2. configure dnsmasq for other purposes too (cobbler server in my case) 3. service dnsmasq restart Actual results: all the dnsmasq processed are killed Expected results: only the OS managed one dnsmasq process should be impacted by the several commands Additional info: With simple changes, where instead of killproc function, I use "killproc -p" (suc as into the httpd init script) I get what expected. Probably my changes are not perfect but a simple start to accomodate what needed. I'm not a coder, but I'm going to attach a diff between my dnsmasq and the one provided. Now, applying the patch, on my system I get: nobody 2648 1 0 Jul17 ? 00:00:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/intracluster.pid --conf-file= --listen-address 172.16.0.1 --except-interface lo --dhcp-range 172.24.0.101,172.31.255.254 nobody 2718 1 0 Jul17 ? 00:00:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.100 nobody 2733 1 0 Jul17 ? 00:00:01 /usr/sbin/dnsmasq -s mydomain.it [root@virtfed storage]# cobbler sync /usr/lib64/python2.6/site-packages/Cheetah/CacheRegion.py:30: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 Shutting down dnsmasq: [ OK ] Starting dnsmasq: [ OK ] [root@virtfed storage]# ps -ef|grep dnsmasq nobody 2648 1 0 Jul17 ? 00:00:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/intracluster.pid --conf-file= --listen-address 172.16.0.1 --except-interface lo --dhcp-range 172.24.0.101,172.31.255.254 nobody 2718 1 0 Jul17 ? 00:00:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.100 nobody 7755 1 0 11:03 ? 00:00:00 /usr/sbin/dnsmasq -s mydomain.it Thanks for your attention. Gianluca
Created attachment 354315 [details] proposed patch to /etc/rc.d/init.d/dnsmasq
how long is a bug supposed to remain in state NEW? Does this mean none opened and first analysed it at all or what? I think that one could be a little disincentivated to open bugs if one month and a half later no feedback at all. At least assigned with some sort of "when I will have time I spent a little of it to this bug... other priorities" Thanks for considering, Gianluca
hi. Can you send a updated patch against dnsmasq rawhide ?
Hi, I tested that the patch against dnsmasq-2.51-1.fc13.x86_64.rpm is the same. In fact, between dnsmasq-2.46-2.fc11.x86_64 and the currently rawhide one, only difference is the line in relation with chkconfig passed from # chkconfig: - 99 01 to # chkconfig: - 49 50
fixed in rawhide. http://koji.fedoraproject.org/koji/taskinfo?taskID=1822319