When`ProtectSystem` is enabled, systemd sets up a separate mount
namespace for the service. Unfortunately, this appears to interfere
with Podman and prevents it from cleaning up containers on shutdown.
To keep the API key a secret, we're encrypting the environment file in
the repository with GnuPG. The decrypted copy only lives in the work
tree and is never committed. Changes have to be re-encrypted and
committed.
Enabling hardware acceleration using VA-API dramatically reduces
`ffmpeg` CPU usage. For this to work, the Frigate container needs
access to the DRI device node.
Since *frigate.service* runs as root, the directories created by
`StateDirectory` are owned by root. The processes inside the container,
therefore, cannot access them. Thus, we have to use `systemd-tmpfiles`
to create the state directories with the appropriate permissions.
The *frigate* container must run as root, so we use a custom user
namespace to map root in the container to an unprivilged user on the
host.
For some reason, Podman (on CoreOS anyway) fails to stop a container
that uses a separate network namespace. It reports "invalid argument"
when attempting to unmount the `netns` file, which then causes the
container to get "stuck" in `Storage` state. Rebooting the host is
apparently the only way to get the container to start again correctly.
Fortunately, there's no particular reason to use an alternate network
namespace for Frigate, so it can use the host's network and avoid this
problem.
Dustin