A while ago, I mentioned seeing an issue with runtime overrides not getting applied. Ran into this now again. I have a complex Caddy configuration that I'd like to debug "in vivo", so I copied the Caddy config from the store to a writable location, ran `systemctl edit --runtime caddy && systemctl daemon-reload && systemctl restart caddy", but a "ps | grep caddy" shows it's still referrencing the old config path.

I made sure to "reset" ExecStart= and ExecReload= each by first declaring them empty before defining the new invocation pointing to the new path, but still… 🤷

A systemctl cat caddy.service includes the runtime override and the new values, but the running service itself also via systemctl show caddy | grep ExecStart points to the original location

that's happening with 257.2 - anyone else ran into something like this?

is this potentially caused by the fact, that the Caddy module itself already throws an override at Caddy?

    Drop-In: /run/systemd/system/caddy.service.d
             └─override.conf
             /nix/store/s2ggv021sz8m4pk62s452pffs0qvh39d-system-units/caddy.service.d
             └─overrides.conf

From the docs:

Drop-in files in /etc/ take precedence over those in /run/ which in turn take precedence over those in /usr/lib/.