Bastian de BylandClaude Opus 5
fb09a01c88
restorecon -Frv over the podman volumes tree descends into two SMB shares mounted inside it -- volumes/photos/immich and volumes/photos/storage, both from truenas -- so it was relabelling the entire remote photo library over the network, on a filesystem that cannot store SELinux xattrs at all. On 2026-08-28 that pinned CPU#0 at 100% system time and the kernel logged six escalating soft lockups: watchdog: BUG: soft lockup - CPU#0 stuck for 1423s! [restorecon:132780] New process creation starved, so sshd accepted connections and then hung during session setup, and the host needed a hard reboot. An earlier run the same day had already been SIGKILLed at 49s, which was the same bug surfacing quietly. -x keeps it on the local filesystem. Measured: 1,279,231 local files walked and relabelled in 29.2s, against never finishing before. The mounts are also x-systemd.automount, so merely walking into them triggers a mount -- there was never anything there to relabel. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
76 lines
2.5 KiB
YAML
76 lines
2.5 KiB
YAML
---
|
|
# -x keeps this on the local filesystem. Two TrueNAS CIFS shares are mounted
|
|
# INSIDE this tree -- volumes/photos/immich and volumes/photos/storage -- and
|
|
# without -x restorecon walked the entire remote photo library over SMB,
|
|
# relabelling a filesystem that cannot even store SELinux xattrs. On 2026-08-28
|
|
# that pinned CPU#0 at 100% system time and the kernel logged escalating soft
|
|
# lockups ("BUG: soft lockup - CPU#0 stuck for 1423s! [restorecon]") until the
|
|
# host could no longer create login sessions and needed a hard reboot. An
|
|
# earlier run the same day had already been SIGKILLed at 49s, which was the
|
|
# same problem surfacing quietly.
|
|
#
|
|
# The mounts are also x-systemd.automount, so merely walking into them triggers
|
|
# a mount -- there is nothing to relabel there and never was.
|
|
- name: restorecon podman
|
|
become: true
|
|
ansible.builtin.command: |
|
|
restorecon -Frxv {{ podman_home }}/.local/share/volumes
|
|
tags:
|
|
- podman
|
|
- selinux
|
|
|
|
# nginx handler removed - nginx infrastructure decommissioned
|
|
|
|
- name: restart firewalld
|
|
become: true
|
|
ansible.builtin.service:
|
|
name: firewalld
|
|
state: restarted
|
|
tags:
|
|
- firewall
|
|
|
|
- name: restart caddy
|
|
become: true
|
|
become_user: "{{ podman_user }}"
|
|
ansible.builtin.command: |
|
|
podman restart caddy
|
|
tags:
|
|
- caddy
|
|
|
|
# Reads /config/Caddyfile, NOT the /etc/caddy/Caddyfile the container starts
|
|
# from, even though both are the same host file. /etc/caddy/Caddyfile is a
|
|
# single-file bind mount, which podman binds by inode; the template module
|
|
# writes a temp file and renames it into place, so every deploy gives the host
|
|
# file a new inode and the container keeps seeing the one it was created with.
|
|
# Reloading from that path silently re-applied the old config -- the change only
|
|
# ever landed when something recreated the container. {{ caddy_path }}/config is
|
|
# also bind-mounted as a *directory* at /config, and a directory mount resolves
|
|
# names at open() time, so /config/Caddyfile is always the file Ansible just
|
|
# wrote.
|
|
- name: reload caddy
|
|
become: true
|
|
become_user: "{{ podman_user }}"
|
|
ansible.builtin.command: |
|
|
podman exec caddy caddy reload --config /config/Caddyfile --adapter caddyfile
|
|
tags:
|
|
- caddy
|
|
- caddy-config
|
|
|
|
- name: reload zomboid systemd
|
|
become: true
|
|
become_user: "{{ podman_user }}"
|
|
ansible.builtin.systemd:
|
|
daemon_reload: true
|
|
scope: user
|
|
tags:
|
|
- zomboid
|
|
|
|
- name: reload podman systemd
|
|
become: true
|
|
become_user: "{{ podman_user }}"
|
|
ansible.builtin.systemd:
|
|
daemon_reload: true
|
|
scope: user
|
|
tags:
|
|
- podman
|