* Avoid duplicate log entries
So far the hassos-supervisor.service starts the hassos-supervisor script
which in turn attaches to the Supervisor container. This causes stdout
and stderr to be forwarded to the service unit, which in turn logs it in
the journal.
However, Docker too logs all stdout/stderr to the journal through the
systemd-journald log driver.
Do not attach to the Supervisor container to avoid logging the
Supervisor twice.
Note that this no longer forwards signals to the container. However, the
hassos-supervisor.service uses the ExecStop= setting to make sure the
container gets gracefully stopped.
* Use image and container name as syslog identifier
By default Docker users the container id as syslog identifier. This
leads to log messages which cannot easily be attributed to a particular
container (since the container id is a random hex string).
Use the image and container name as syslog identifier.
Note that the Docker journald log driver still stores the container id
as a separate field (CONTAINER_ID), in case the particular instance need
to be tracked.
* Start ha-cli on tty1 instead of a getty
Instead of starting a getty start the ha-cli directly. This will show
the banner right on startup with the important information such as IP
address of the instance or the URL to reach it.
* Use default shell as root shell instead of HA CLI
Instead of using the ha-cli.sh script as login shell use the regular
shell. Amongst other things, this allows to run VS Code devcontainers
remotely via SSH or using scp. The HA CLI is still available using the
`ha` command.
* Enable systemd-time-wait-sync.service by default
Enable the systemd-time-wait-sync.service by default. This allows to use
the time-sync.target which allows to make sure services only get started
once the time is synchronized.
* Make sure time is synchronized when starting hassos-supervisor.service
Use the time-sync.target to make sure that the Supervisor gets stsarted
after the time has been synchronized.
* Set timeout for systemd-time-wait-sync.service
Don't delay startup forever in case time synchronization doesn't work.
This allows to boot the system even without Internet connection.
* Disable systemd-logind support for udisks2
Currently udisks2 uses systemd-logind to prevent the system from
rebooting or similar operations while udisks operations are ongoing.
Unfortunately this stops us from using udisks2 during early boot since
systemd-logind is not ready at this point. Make the dependency
configureable so we can opt-out of using systemd-logind.
* Make dbus.service/socket and udisks2.service/socket available early
Disable default dependencies. This avoids those services to be ordered
after sysinit.target, and makes them available before local-fs.target
is reached. All mounts like mnt-data.mount are ordered before
local-fs.target, so breaking this dependency allows to use D-Bus before
mounting local file systems.
This seems fine when using the system bus directly from /run (instead of
/var/run, which is anyway a symlink to /run normally). It seems that
udisks misses /var/lib/udisks2 but it seems not to be required for the
features used so far.
So far the exit code has been evaluated, which seems to be non-zero even
with a regular term signal. With that systemd assumed the service is in
a failed state, when in fact this seems the regular behavior of dropbear
when shutting it down.
* Add --cpu-rt-runtime to allow Docker allocate real-time CPU time (#1235)
* Enable Supervisor's CPU bandwith allocation feature (#1235)
Since we have CONFIG_RT_GROUP_SCHED enabled in the Home Assistant OS
kernel the Supervisor needs to enable CPU bandwith allocation for
Add-Ons which need real-time scheduling. Set the appropriate environment
variable.
It seems that on certain setups the default DNS over TLS mode
"opportunistic" causes delays of ~10s when trying to resolve names. This
is probably caused by providers and/or firewall setups not properly rejecting
connections on port 853.
It seems that also other distributions (such as Arch Linux) still
disable DNS over TLS currently. Side step issues with DNS over TLS by
disabling it for now.
Old Laptops are a popular choice to run Home Assistant: They have low
power consumption, are relatively fast and cheap to come by. However,
closing their lid by default puts a Linux system into suspend. This is
not what the typical user of Home Assistant OS wants. Ignore lid
activity in any state by default.
* Add resolved.conf to disable stub resolver and DNSSEC
There are Add-Ons which try to bind port 53 on all interfaces including
127.0.0.53. Disable the stub resolver to make them continue working. We
don't need the resolver currently anyway.
Also disable DNSSEC to make sure the baords can access a NTP time server
even when their time is incorrect (since DNSSEC validation may fail).
This is a known chicken-egg problem with systemd-resolved/systemd-timesyncd
and might be addressed in a future version, with what we can reenable
DNSSEC:
https://github.com/systemd/systemd/issues/5873
* Make sure resolve gets added only once to nsswitch.conf
Only add resolve to nsswitch.conf if not already present.
On systems where ACPI support is present as inidcated by the presence of
/proc/acpi (e.g. on OVA compatible hypervisors), we want to properly
shut down the system when the power button is pressed (or the hypervisor
simulates this kind of event to the guest machine that executes hassos).
This changeset provides the following basic infrastructure for this
feature to work as expected:
* a systemd service to start acpid, if ACPI support can be assumed
* an acpid configuration directory
* a trivial shutdown script to invoke when a PWR event is registered
