• 1 Post
  • 2 Comments
Joined 3 years ago
Cake day: June 16th, 2023

  • Based on your systemd output, it looks like the system is taking a long while to decrypt your drive. Is it a spinning disk, or an SSD?

    I’m not sure if the PC repair shop specifically checked your drive, but it might be worth swapping out for another. Or maybe run some speed tests and/or diagnostics to see if there’s something funky going on.

    You could also try an unencrypted install to see if the problem persists.


  • I set up a very straightforward Godot dev environment yesterday using toolbox which is built on top of rootless Podman.

    • Create a new fedora toolbox
    • Enter toolbox
    • Install DotNet dependencies, git, etc with dnf
    • Install Godot binary from release page
    • Turns out there were other dependencies I needed
    • Godot wanted a few Wayland libs on the container, so I installed Weston (maybe overkill)
    • Godot wanted libxrandr so I added that too
    • Godot just works ™

    The nice thing about toolbox is that it uses my native host Wayland compositor. So whatever I have running in the toolbox can be interacted normally through sway (my host WM).

    You can either distribute a container image with your given toolbox configured, or just document the setup steps.


I generally let my server do its thing, but I run into an issue consistently when I install system updates and then reboot: Some docker containers come online, while others need to be started manually. All containers were running before the system shut down.

  • My containers are managed with docker compose.
  • Their compose files have restart: always
  • It’s not always the same containers that fail to come online
  • Some of them depend on an NFS mount point being ready on the host, but not all

Host is running Ubuntu Noble

Most of these containers were migrated from my previous server, and this issue never manifested.

I wonder if anyone has ideas for what to look for?

SOLVED

The issue was that docker was starting before my NFS mount point was ready, and the containers which depended on it were crashing.

Symptoms: journalctl -b0 -u docker showed the following log lines (-b0 means to limit logs to the most recent boot):

level=error msg="failed to start container" container=fe98f37d1bc3debb204a52eddd0c9448e8f0562aea533c5dc80d7abbbb969ea3 error="error while creating mount source path '/mnt/nas/REDACTED': mkdir /mnt/nas/REDACTED: operation not permitted"
...
level=warning msg="ShouldRestart failed, container will not be restarted" container=fe98f37d1bc3debb204a52eddd0c9448e8f0562aea533c5dc80d7abbbb969ea3 daemonShuttingDown=true error="restart canceled" execDuration=5m8.349967675s exitStatus="{0 2024-10-29 00:07:32.878574627 +0000 UTC}" hasBeenManuallyStopped=false restartCount=0

I had previously set my mount directory to be un-writable if the NFS were not ready, so this lined up with my expectations.

I couldn’t remember how systemd names mount points, but the following command helped me find it: systemctl list-units -t mount | grep /mnt/nas

It gave me mnt-nas.mount as the name of the mount unit, so then I just added it to the After= and Requires= lines in my /etc/systemd/system/docker.service file:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com/
After=network-online.target docker.socket firewalld.service containerd.service time-set.target mnt-nas.mount
Wants=network-online.target containerd.service
Requires=docker.socket mnt-nas.mount
...