Skip to content

manager: save timestamps when shutting down

Íñigo Huguet requested to merge ih/conn_timestamp into main

Summary

Save active connections' timestamps to disk when stopping NetworkManager to ensure right activation order on next start.

Purpose

Connection timestamps are updated (saved to disk) on connection up and down. This way, the last used connection will take precedence for autoconnect if they have the same priority.

But as we don't actually do connection down when NM stops, the last connection timestamp of all active connections is the timestamp of when they were brought up. Then, the activation order might be wrong on next start.

One case where timestamps are wrong (although it is not clear how important it is because the connections are activated on different interfaces):

  1. Activate con1 <- timestamp updated
  2. Activate con2 <- timestamp updated
  3. Deactivate con2 <- timestamp updated
  4. Stop NM <- timestamp of con2 is higher than con1, but con1 was still active when con2 was brought down.

Other case that is reproducible (from https://issues.redhat.com/browse/RHEL-35539):

  1. Activate con1
  2. Activate con2 on same interface:
    • As a consequence con1 is deactivated and its timestamp updated
    • The timestamp of con2 is also updated
  3. Stop NM <- timestamp of con1 and con2 is the same, next activation order will be undefined.

Fix by saving the timestamps on NM shutdown.

Resolves: https://issues.redhat.com/browse/RHEL-35539
NetworkManager-ci!1687 (merged)

Checklist

Please read https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/CONTRIBUTING.md before opening the merge request. In particular, check that:

  • the subject for all commits is concise and explicative
  • the message for all commits explains the reason for the change
  • the source is properly formatted
  • any relevant documentation is up to date
  • you have added unit tests if applicable
  • the NEWS file is updated when the change deserves to be mentioned, for example for new features, behavior changes, API deprecations, etc.

Merge request reports