Bug 512664

Summary: modify init script for libvirt and cobbler integration
Product: [Fedora] Fedora Reporter: Gianluca Cecchi <gianluca.cecchi>
Component: dnsmasqAssignee: Itamar Reis Peixoto <itamar>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: itamar, jima, markmc, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-22 11:49:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed patch to /etc/rc.d/init.d/dnsmasq none

Description Gianluca Cecchi 2009-07-20 09:13:03 UTC
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

Comment 1 Gianluca Cecchi 2009-07-20 09:13:56 UTC
Created attachment 354315 [details]
proposed patch to /etc/rc.d/init.d/dnsmasq

Comment 2 Gianluca Cecchi 2009-09-08 16:03:35 UTC
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

Comment 3 Itamar Reis Peixoto 2009-11-19 07:51:26 UTC
hi.

Can you send a updated patch against dnsmasq rawhide ?

Comment 4 Gianluca Cecchi 2009-11-22 11:04:06 UTC
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

Comment 5 Itamar Reis Peixoto 2009-11-22 11:49:45 UTC
fixed in rawhide.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1822319