Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#713 - netifd: substantially more IFUP events are being created #5723

Open
openwrt-bot opened this issue Apr 17, 2017 · 5 comments
Open

FS#713 - netifd: substantially more IFUP events are being created #5723

openwrt-bot opened this issue Apr 17, 2017 · 5 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Apr 17, 2017

EricLuehrsen:

I have noticed that some services reloaded with a procd "interface.*" raw trigger are reloading on a much more frequent cadence (few minutes or so). LEDE 17.01 does not do this. LEDE Trunk does. I can not find an obvious cause in procd. Though procd should not stop-start for reload without a command line change or explicit file under watch. Perhaps netifd commit a03216660797173fbe67866f75564e3fec9c1e8d is generating unusual numbers of IFUP.

procd_add_raw_trigger "interface.*" 2000 /etc/init.d/[script] reload

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 17, 2017

EricLuehrsen:

I can confirm this using tools that use an interface trigger with optional interfaces. If WAN (ip4 only) and not WAN6 is used restarts almost never occur. If WAN6 is included, then restarts are occurring every few minutes.

for iface in $ifacelist
do
    procd_add_interface_trigger "interface.*" "$iface" /etc/init.d/[script] [command]
done

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 19, 2017

dedeckeh:

Before netifd commit https://git.lede-project.org/?p=project/netifd.git;a=commitdiff;h=b8ef742bd04ebef324ae11aee56c6e1d2cb7e0ad interface update events were send without an IP address/route/data/prefix change actually happening.
This commit fixed the issue of unnecessary interface update events but as reported in #346 this caused a regression in the hnetd daemon implementation as it was relying on the "unnecessary" interface update events to pick up IPv6 prefix lifetime changes.
This was fixed in netifd commit https://git.lede-project.org/?p=project/netifd.git;a=commit;h=a03216660797173fbe67866f75564e3fec9c1e8d which explicitly triggers interface update events allowing the hnetd daemon to pick IPv6 prefix lifetime updates.
So reverting this commit will break hnetd daemon again or making it a controllable feature as reported in http://lists.infradead.org/pipermail/lede-dev/2017-April/007065.html is also not a clean solution.
Packages installing interface triggers are now triggered by procd when an interface parameter changes; a more sane approach would be to allow a procd interface trigger subscription for a specific interface parameter changes as most daemons are not interested in route or IPv6 prefix changes

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 25, 2017

EricLuehrsen:

If procd isn't up to the task yet, then is changing netifd now the right solution?
http://lists.infradead.org/pipermail/lede-dev/2017-April/007162.html

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jan 3, 2018

netprince:

I can confirm this behavior, I am getting dnsmasq reload events triggered 2-3 times per minute.

@alanswanson
Copy link
Contributor

@alanswanson alanswanson commented May 10, 2022

I encountered this with a DSL router setup for a wan6 interface using @wan device configured for dhcpv6.

The actual question is, as Homenet appears dead with no updates since 2016 and whilst some routing commits even the OpenWrt wiki warns that it's dead.

Can commit https://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=a03216660797173fbe67866f75564e3fec9c1e8d now be reverted? No other users of lifetime changes?

Addendum: This would also close #6454.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants