f3808b872f
This changes the retransmission timeout algorithm for requests other than RENEW and REBIND. Previously, the retransmission timeout started at 2 seconds, then doubling each retransmission up to a max of 64 seconds. This is changed to match what RFC2131 section 4.1 describes, which skips the initial 2 second timeout and starts with a 4 second timeout instead. Note that -1 to +1 seconds of random 'fuzz' is added to each timeout, in previous and current behavior. This change is therefore slightly slower than the previous behavior in attempting retransmissions when no server response is received, since the first transmission times out in 4 seconds instead of 2. Since TRANSIENT_FAILURE_ATTEMPTS is set to 3, the previous length of time before a transient failure was reported back to systemd-networkd was 2 + 4 + 8 = 14 seconds, plus, on average, 3 seconds of random 'fuzz' for a transient failure timeout between 11 and 17 seconds. Now, since the first timeout starts at 4, the transient failure will be reported at 4 + 8 + 16 = 28 seconds, again plus 3 random seconds for a transient failure timeout between 25 and 31 seconds. Additionally, if MaxAttempts= is set, it will take slightly longer to reach than with previous behavior.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.