Currently systemd-timesyncd tries to connect to the NTP server quite
early at boot-up. At this time the network connection has not been
established yet. This causes resolving the NTP server to fail and
a rate limit kicks in which makes systemd-timesyncd wait for 30s until
the next attempt.
Lowering the retry attempt to 10s makes systemd-timesyncd connecting
shortly after.
Note: The rate limit is 10 attempts per 10s. Because the attempts are
immediately exhausted lowering connection retry attempt below 10s
adds no benefit.
See also: https://github.com/systemd/systemd/issues/24298
* buildroot 97287bbebf...0397d9c8f0 (5):
> package/docker-proxy: bump version to f6ccccb1c082
> package/containerd: security bump to 1.6.6
> package/docker-engine: bump to version 20.10.17
> package/docker-cli: bump to version 20.10.17
> package/runc: bump to version 1.1.3
* Load container images descending by size
Loading container images using docker load seems to require more space
at load time (which gets freed after loading). Loading the largest
container first avoids running out of space.
* Bump buildroot
* buildroot 99b62b8bd3...97287bbebf (3):
> package/dbus-broker: bump to release 32
> package/dbus-broker: new package
> Merge pull request #3 from home-assistant/2022.02.x-haos-cgroup-v2
* Use dbus-broker as default D-Bus broker
The dbus-broker (Linux D-Bus Message Broker) aims to be a high
performance and reliable D-Bus broker which can be used as a drop in
replacement to the reference implementation D-Bus broker. In tests it
showed significantly better performance especially when routing BLE
messages.
* Allow dbus-broker to start early
For HAOS device wipe feature we need haos-agent.service and
udisk2.service early. Both require a working D-Bus broker.
The options PrivateTmp and PrivateDevices add additional After=
orderings which doesn't allow dbus-broker to be started early.
* Fix D-Bus dependency
D-Bus services should just depend on dbus.socket.
* Disable real-time scheduling
It seems that Linux' cgroup v2 currenlty does not support RT scheduling.
* Remove Supervisor RT support flag
With CGroups v2 we can no longer support CPU resource allocation for
realtime scheduling.
* Bump OS Agent to 1.3.0 for CGroups v2 support
This makes the Red+Blue Button cause the boot loader to wipe start4.elf,
which is essential for the boot loader to boot from eMMC. With the file
missing, the Raspberry Pi firmware will continue its boot flow and boot
from USB host next. This allows to run the Home Assistant OS Installer
from a USB flash drive again.
A faster restart policy is unlikely to help. Increasing the limit makes
it less likely to run into cloud service rate limits (e.g. container
registry).
* chore: Set permissions for GitHub actions
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.
* Remove global permissions which are set implicitly
With restrictive settings in the global GitHub Action permission settings
those permissions are given implicitly.
Co-authored-by: neilnaveen <42328488+neilnaveen@users.noreply.github.com>
Co-authored-by: Joakim Sørensen <hi@ludeeus.dev>
Co-authored-by: Stefan Agner <stefan@agner.ch>
Some applications try to increase the buffers for performance reason. The
QUIC Go implementation for instance tries to request a 2048 kiB buffer
size.
The kernel default depends on skubuf size (which is architecture
dependent), but it is memory size independet and typically around 200 kiB
(see [1]).
Other network tuning guides suggest 16MiB for 1GB ethernet, as well as
changing the default as well as maximum bufffer size (see [2]). This
conservatively increases the maximum buffer size to 4MiB.
[1]: https://elixir.bootlin.com/linux/v5.15.45/source/include/net/sock.h#L2742
[2]: https://nateware.com/2013/04/06/linux-network-tuning-for-2013/
