| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| | |
Fix dhcpv4 renew/rebind intervals to match rfc2131
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
timeout
Previous commits changed the dhcpv4 retransmission algorithm to be
slightly slower, changing the amount of time it takes to notify
systemd-networkd that the dhcpv4 configuration has (transiently)
failed from around 14 second up to 28 seconds.
Since the test_dhcp_client_with_ipv4ll_without_dhcp_server test
configures an interface to use dhcpv4 without any operating dhcpv4
server running, it must increase the amount of time it waits for
the test interface to reach degraded state.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use the request timeout algorithm specified in RFC2131 section 4.4.5 for
handling timed out RENEW and REBIND requests.
This changes behavior, as previously only 2 RENEW and 2 REBIND requests
were sent, no matter how long the lease lifetime. Now, requests are
send according to the RFC, which results in starting with a timeout
of 1/2 the t1 or t2 period, and halving the timeout for each retry
down to a minimum of 60 seconds.
Fixes: #17909
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The parsing of the dhcpv4 lease lifetime, as well as the t1/t2
times, is simplified by this commit.
This differs from previous behavior; previously, the lease lifetime and
t1/t2 values were modified by random 'fuzz' by subtracting 3, then adding
a random number between 0 and (slightly over) 2 seconds. The resulting
values were therefore always between 1-3 seconds shorter than the value
provided by the server (or the default, in case of t1/t2). Now, as
described in RFC2131, the random 'fuzz' is between -1 and +1 seconds,
meaning the actual t1 and t2 value will be up to 1 second earlier or
later than the server-provided (or default) t1/t2 value.
This also differs in handling the lease lifetime, as described above it
previously was adjusted by the random 'fuzz', but the RFC does not state
that the lease expiration time should be adjusted, so now the code uses
exactly the lease lifetime as provided by the server with no adjustment.
|
| |
| |
| |
| |
| |
| | |
RFC2131, providing the details for dhcpv4, has specific retransmission
intervals that it outlines. This adds functions to compute the timeouts
as the RFC describes.
|
| |
| |
| |
| | |
Add fields to dhcp4 client to track t1, t2, and lease expiry times
|
| | |
|
| |
| |
| |
| |
| | |
These two judgement can't judge that two entries are repeating fully.
So i think seqnum is needed to make full judgement.
|
| | |
|
| | |
|
| |
| |
| | |
Updated the patch as per review comments.
|
| |
| |
| |
| | |
Added debug log to detect special character in dbus interface names.
Helps to detect a case mentioned in https://github.com/systemd/systemd/issues/14636
|
| |
| |
| |
| |
| |
| |
| |
| | |
Currently translated at 61.4% (115 of 187 strings)
Co-authored-by: Fabian Affolter <mail@fabian-affolter.ch>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/master/de/
Translation: systemd/master
|
| |
| |
| |
| |
| |
| |
| | |
Use symlink_atomic_label() instead of symlink_atomic() as the symlink
may need a different label than the parent directory.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
|
|\ \
| | |
| | | |
core/namespace: do not ignore non-EPERM mount error
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
hostname"
This reverts commit 0ebc9f23faf5586f8a9250c3be08773eb3f8d2da.
With the previous commit, these files should always exist.
Closes #17979.
|
| | |
| | |
| | |
| | | |
Follow-up for 61f8a7bd3e20222617fc59f398071daf2af86f96.
|
| | |
| | |
| | |
| | | |
Support gcc 8 on arm
|
|\ \ \
| | | |
| | | | |
Add debug logging for varlink
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When something fails, we need some logs to figure out what happened.
This is primarily relevant for connection errors, but in general we
want to log about all errors, even if they are relatively unlikely.
We want one log on failure, and generally no logs on success.
The general idea is to not log in static functions, and to log in the
non-static functions. Non-static functions which call other functions
may thus log or not log as appropriate to have just one log entry in the
end.
|
| | | |
| | | |
| | | |
| | | | |
This is useful for contexts where only debug-level messages are allowed.
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
```
❯ ssh sus@xx.xx.xx.xx
Last login: Sat Nov 14 17:32:08 2020 from 10.104.45.138
17:36:19 up 0 min, 0 users, load average: 0.00, 0.00, 0.00
> systemd-analyze blame
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
> systemd-analyze blame
43.954s systemd-time-wait-sync.service
1.969s systemd-networkd-wait-online.service
1.559s cloud-init-local.service
1.039s cloud-init.service
414ms cloud-final.service
387ms dracut-initqueue.service
382ms initrd-switch-root.service
380ms cloud-config.service
198ms systemd-journal-flush.service
136ms systemd-udev-trigger.service
115ms initrd-parse-etc.service
97ms systemd-timesyncd.service
84ms systemd-journald.service
```
After made it configurable and set to 5s
```
❯ ssh sus@xx.xx.xx.xx
Last login: Sat Nov 14 18:41:42 2020 from 10.104.45.138
18:42:36 up 0 min, 0 users, load average: 0.16, 0.03, 0.01
> systemd-analyze blame
10.450s systemd-time-wait-sync.service
8.303s systemd-networkd-wait-online.service
1.621s cloud-init-local.service
1.068s cloud-init.service
```
|
|\ \ \
| | | |
| | | | |
network: introduce log_routing_policy_rule()
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
As routing policy rules are managed by Manager.
|
|\ \ \ \
| | | | |
| | | | | |
network: introduce log_address_debug()
|
| | | | | |
|
| |/ / / |
|
|\ \ \ \
| | | | |
| | | | | |
network: introduce log_route_debug()
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| |_|/
|/| | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes #17860.
|
|/ /
| |
| |
| |
| |
| | |
If they do not exist, hostname or domainname cannot be modified. So, it is ok.
Fixes #17866, especially https://github.com/systemd/systemd/issues/17866#issuecomment-744118614.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
bpffs fully respects mount namespaces since kernel version 4.7
References:
- https://github.com/torvalds/linux/commit/e27f4a942a0ee4b84567a3c6cfa84f273e55cbb7
- https://github.com/torvalds/linux/commit/612bacad78ba6d0a91166fc4487af114bac172a8
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The commit 6f3ac0d51766b0b9101676cefe5c4ba81feba436 drops the prefix and
suffix in TAGS= property. But there exists several rules that have like
`TAGS=="*:tag:*"`. So, the property must be always prefixed and suffixed
with ":".
Fixes #17930.
|
|\ \
| | |
| | | |
Enable logging in nss modules
|
| | |
| | |
| | |
| | |
| | | |
No logging is done directly by nss-mymachines.c code, but we call into sd-bus,
which will log.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When the .so module is loaded, it gets a separate copy of stuff in src/basic,
including the log level variables. So any logging settings are unaffected by
the loading program calling log_parse_environment() or such. Let's also parse
the environment here so that we can have nice logging.
Initialization is done from each exported function, and pthread_once_t is used
to avoid duplicate initialization. I didn't merge PROTECT_ERRNO into
NSS_ENTRYPOINT_BEGIN because UNPROTECT_ERRNO is called in a bunch of places
and it would feel strange to have PROTECT_ERRNO hidden, but not UNPROTECT_ERRNO.
The most interesting stuff in this module is the varlink messages, and any
potential errors in json. So let's enable json logging when debug messages are
enabled.
With those changes, figuring out the issue in
https://github.com/systemd/systemd/pull/17823 is trivial:
$ LD_LIBRARY_PATH=build/ SYSTEMD_LOG_COLOR=1 SYSTEMD_LOG_LOCATION=1 SYSTEMD_LOG_LEVEL=debug getent hosts mirrors.fedoraproject.org
src/shared/varlink.c:237: n/a: varlink: setting state idle-client
src/shared/varlink.c:1240: n/a: Sending message: {"method":"io.systemd.Resolve.ResolveHostname","parameters":{"name":"mirrors.fedoraproject.org","family":10}}
src/shared/varlink.c:240: n/a: varlink: changing state idle-client → calling
src/shared/varlink.c:588: n/a: New incoming message: {"parameters":{"addresses":[{"ifindex":0,"family":10,"address":[42,5,208,20,0,16,120,3,247,116,77,124,226,119,164,87]},{"ifindex":0,"family":10,"address":[42,5,208,28,12,106,204,3,38,58,132,9,185,97,126,2]},{"ifindex":0,"family":10,"address":[38,32,0,82,0,3,0,1,222,173,190,239,202,254,254,215]},{"ifindex":0,"family":10,"address":[38,5,188,128,48,16,6,0,222,173,190,239,202,254,254,217]},{"ifindex":0,"family":10,"address":[38,4,21,128,254,0,0,0,222,173,190,239,202,254,254,209]},{"ifindex":0,"family":10,"address":[38,32,0,82,0,3,0,1,222,173,190,239,202,254,254,214]},{"ifindex":0,"family":10,"address":[38,16,0,40,48,144,48,1,222,173,190,239,202,254,254,211]},{"ifindex":0,"family":10,"address":[32,1,65,120,0,2,18,105,0,0,0,0,0,0,254,210]}],"name":"wildcard.fedoraproject.org","flags":1}}
src/shared/varlink.c:240: n/a: varlink: changing state calling → called
src/shared/varlink.c:240: n/a: varlink: changing state called → idle-client
src/nss-resolve/nss-resolve.c:84: (string):1:40: JSON field 'ifindex' is out of bounds for an interface index.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
E.g. in nss-resolve it is still useful to print the location of the error:
src/test/test-nss.c:231: dlsym(0x0x1dc6fb0, _nss_resolve_gethostbyname2_r) → 0x0x7fdbfc53f626
(string):1:40: JSON field ifindex is out of bounds for an interface index.
I opted to use a partially duplicated if condition to avoid nesting. It's nice
to have the log calls vertically aligned. The compiler will optimize this nicely.
|