Ask Your Question

neutron-rootwrap appears unable to kill dnsmasq processes

asked 2015-08-11 06:12:17 -0500

DanielK gravatar image

Hello everyone

I have run into a problem with openstack kilo on CentOS 7 where a specific hypervisor's instances did not get addresses assigned from the network controller anymore. Investigation lead me to the dhcp-agent logs which stated that the agent was "Unable to enable dhcp" for that machine. This was due to an error thrown by the neutron-rootwrap

/usr/bin/neutron-rootwrap: Unauthorized command: kill -9 14137 (no filter matched)

14137 is the pid of the dnsmasq process in this case.

I checked my dhcp.filter in /etc/neutron/rootwrap.d and made sure it matches with the newest one at (

I also checked the rootwrapper code and as far as I could see it there is indeed no way the KillFilter which neutron-rootwrap is using can take a pid as argument, so it would make sense for that command to fail.

Is this a bug or did I miss something?

BTW, once I killed the dnsmasq process by hand everything worked fine again but I am afraid that problem could re-appear in the future.

Kind regards

edit retag flag offensive close merge delete


Had you at any point upgraded dnsmasq (while the dhcp agent was running)? If you have automatic upgrades enabled, check /var/log/yum.log to see if such an upgrade happened.

larsks gravatar imagelarsks ( 2015-08-14 15:58:32 -0500 )edit

Yes, that did indeed happen.

Can that be the source of the problem? If so, would you know why that causes the issue?


DanielK gravatar imageDanielK ( 2015-08-20 02:18:02 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2015-08-24 09:22:27 -0500

larsks gravatar image

It looks you have hit this bug that I reported a few weeks ago. The problem is that rootwrap is attempting to validate an attempt to run the kill command with root privileges, and it is trying to match the path of the process being killed against a list of known paths (like /usr/bin/dnsmasq).

The error occurs because during an upgrade the file is first renamed and then deleted. The result is that the path stored in /proc/<PID>/exe no longer matches any of the known paths.

This change (which has not yet merged) should correct the problem.

edit flag offensive delete link more


Thanks, good to hear. I reckon since you already committed a fix it will soon be available as update and the problem will not reappear after that.

DanielK gravatar imageDanielK ( 2015-08-31 03:43:54 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2015-08-11 06:12:17 -0500

Seen: 556 times

Last updated: Aug 24 '15