| Summary: | systemd-timesyncd "Network configuration changed" spam on IPv6 router advertisements | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Laurentiu Nicola <lnicola> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | daniel.schoemer, moebius282, radek, saintdev, teg |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Log of IPv6 router advertisements
Log of systemd-timesyncd ip monitor log networkd debug log timesyncd debug log tshark -f ip6 log |
||
|
Description
Laurentiu Nicola
2014-12-19 18:38:42 UTC
I notice the same behaviour of systemd-timesyncd after upgrading from 217 to 218. To me it seems to be related to the event(s) received by timesyncd (sent by networkd?) on IPv6 router advertisements. Each time my home router sends a router advertisment, timesyncd "thinks" the network configuration has changed. See attached ipv6-router-advertisment.log and systemd-timesyncd.log. My home router is using radvd 1.13. radvd is sents router advertisements every few seconds. As far as I understood, this is the default behaviour of radvd. Created attachment 111081 [details]
Log of IPv6 router advertisements
Created attachment 111082 [details]
Log of systemd-timesyncd
I compared running combinations of networkd and timesyncd of systemd 217 and 218: networkd | timesyncd | result -------- | --------- | ------ 217 | 217 | OK 218 | 218 | timesyncd "net conf changed" on IPv6 router adv. 217 | 218 | timesyncd "net conf changed" on IPv6 router adv. 218 | 217 | OK Daniel Schömer's analysis is correct, I can confirm the link between IPv6 router advertisements and the "network configuration changed" messages. Fixed in git. Actually, as Zbigniew pointed out to the ML my fix of just suppressing the log output is not really enough, we should also not constantly restart the NTP query logic when the system gets an IPv6 RA packet... This would mean we'd send a bunch of NTP packets for each RA packet, and that would be bad. Reopening hence. Not sure what the best strategy for this is though... If the kernel wakes us up even on each RA, then we kinda need to compare the whole network config before doing anything. And I am not sure I want that... Tom, would it be possible to filter those messages on systemd-networkd side by detecting state changes which do not change anything? Based on attachment #1 [details] [review], those router advertisements are actually all the same. Hm, if networkd is causing this we should definitely filter it. Looking at the code I could not figure out what is causing us to send these repeated announcements though... We send messages on state changes and when an interface gets a new address (but not when we change an existing address). Could someone who can reproduce this please run both networkd and timesyncd with SYSTEMD_LOG_LEVEL=debug and upload the logs? Would also be useful to run "ip monitor" at the same time as that will catch any spurious NEW_ADDR / NEW_LINK messages that we may be mishandling. Created attachment 113482 [details]
ip monitor log
Created attachment 113483 [details]
networkd debug log
Created attachment 113484 [details]
timesyncd debug log
Created attachment 113485 [details]
tshark -f ip6 log
I uploaded the logs of ip monior, networkd, timesyncd and tshark. As of systemd 219, timesyncd is syncing at expected intervals (64s, ...) Closing then. Please reopen if you see the issue again. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.