Bug 822374

Summary:	NetworkManager not always triggering dispatcher scripts
Product:	[Fedora] Fedora	Reporter:	Jason Haar <jhaar>
Component:	NetworkManager	Assignee:	Dan Williams <dcbw>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	clancy.kieran+redhat, danw, dcbw, jklimes
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:	2013-02-13 13:55:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jason Haar 2012-05-17 08:05:40 UTC

Description of problem:

I need to trigger scripts whenever network changes occur - in particular I fiddle with /etc/resolv.conf. With Fedora-15 I put scripts within /etc/NetworkManager/dispatcher.d/ to do this

Under F16, they *mostly* work - but every now and then NetworkManager triggers, and those scripts don't get executed - and /etc/resolv.conf gets overwritten and my network breaks (corporate VPN thing)
 
Version-Release number of selected component (if applicable):


How reproducible:

every day?

Steps to Reproduce:
1. wait
2. it happens
3.
  
Actual results:

/etc/resolv.conf is overwritten and there's no evidence my scripts executed

Expected results:

dispatcher should call the scripts with up/down/whatever - it's up to them whether they do anything...

Additional info:

I put "logger" statements in my scripts (they show up as "reset_*"), so that whenever NetworkManager successfully calls them, they'll show up in the syslogs. Below is a sample of when it works and then doesn't work. You can see that NetworkManager was triggering something for some reason - but my scripts weren't executed. I suspect "Policy set..." is the issue - ie it doesn't trigger dispatcher.d scripts, and yet does fiddle with /etc/resolv.conf?


May 17 17:27:03 jhaar-fc-nzcl NetworkManager[1230]: <info> (wlan0): device state change: ip-config -> activated (reason 'none') [70 100 0]
May 17 17:27:03 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv4 routing and DNS.
May 17 17:27:03 jhaar-fc-nzcl NetworkManager[1230]: <info> Activation (wlan0) successful, device activated.
May 17 17:27:03 jhaar-fc-nzcl NetworkManager[1230]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) complete.
May 17 17:27:04 jhaar-fc-nzcl 09-trimble-reset-settings: called with wlan0 up
May 17 17:27:04 jhaar-fc-nzcl 09-trimble-reset-settings: finished
May 17 17:27:04 jhaar-fc-nzcl avahi-daemon[1231]: Registering new address record for fe80::224:d7ff:fe7b:ab60 on wlan0.*.
May 17 17:27:04 jhaar-fc-nzcl /etc/dhcp/dhclient.d/reset_dns.sh: dhclient called
May 17 17:27:04 jhaar-fc-nzcl /usr/local/bin/reset_dns:  updated /etc/resolv.conf
May 17 17:27:05 jhaar-fc-nzcl avahi-daemon[1231]: Registering new address record for 2001:470:828b:0:224:d7ff:fe7b:ab60 on wlan0.*.
May 17 17:27:05 jhaar-fc-nzcl avahi-daemon[1231]: Withdrawing address record for fe80::224:d7ff:fe7b:ab60 on wlan0.
May 17 17:27:05 jhaar-fc-nzcl NetworkManager[1230]: <info> Activation (wlan0) Stage 5 of 5 (IPv6 Commit) scheduled...
May 17 17:27:05 jhaar-fc-nzcl NetworkManager[1230]: <info> Activation (wlan0) Stage 5 of 5 (IPv6 Commit) started...
May 17 17:27:06 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv4 routing and DNS.
May 17 17:27:06 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv6 routing and DNS.
May 17 17:27:06 jhaar-fc-nzcl NetworkManager[1230]: <info> Activation (wlan0) Stage 5 of 5 (IPv6 Commit) complete.
May 17 17:27:09 jhaar-fc-nzcl reset_settings: called as reset_settings wlan0
May 17 17:27:09 jhaar-fc-nzcl reset_settings: Already running as 19423
May 17 17:27:10 jhaar-fc-nzcl /usr/local/bin/reset_dns:  updated /etc/resolv.conf
May 17 17:27:11 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv4 routing and DNS.
May 17 17:27:11 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv6 routing and DNS.
May 17 17:27:35 jhaar-fc-nzcl /usr/local/bin/reset_dns:  updated /etc/resolv.conf
May 17 17:27:45 jhaar-fc-nzcl reset_settings: finished in 50 sec
May 17 19:14:20 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv4 routing and DNS.
May 17 19:14:20 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv6 routing and DNS.
May 17 19:15:46 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv4 routing and DNS.
May 17 19:15:46 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv6 routing and DNS.
May 17 19:19:31 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv4 routing and DNS.
May 17 19:19:31 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv6 routing and DNS.
May 17 19:38:11 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv4 routing and DNS.
May 17 19:38:11 jhaar-fc-nzcl NetworkManager[1230]: <info> Policy set 'whanau' (wlan0) as default for IPv6 routing and DNS.

Comment 1 Jirka Klimes 2012-07-26 11:54:26 UTC

There were some fixes for touching resolv.conf lately.
Would you mind trying 0.9.6-rc2 build and report if it helps:
http://koji.fedoraproject.org/koji/buildinfo?buildID=344188

Otherwise, please run

sudo /usr/libexec/nm-dispatcher.action --debug --persist

reproduce the issue and attach the output of the program.

Comment 2 Fedora End Of Life 2013-01-16 13:13:25 UTC

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Fedora End Of Life 2013-02-13 13:55:28 UTC

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.