Hello, im running into an issue updating my relay. I followed the steps described here in the docs (couldnt link for some reason)
but im getting this error:
Has anyone else ran into this issue that can help?
Thanks in advance 
Do you mind specifying the OS?
sorry! the server is debian 12.14, the computer im running the script from is cachyOS
There were some issues a bit ago with some systems using systemd-resolved and /etc/resolv.conf being a symlink rather than a regular file. All of those should have been sorted in the latest git code release, did you do a fresh pull and check out tag 1.11.0 to deploy? Test with git log -1 the last commit message should be the prepare for 1.11.0 msg.
Edit: it would probably help if you showed us a ls -ld /etc/resolv.conf so we can see what the file looks like on your server as it stands. Could provide a clue…
Yeah so I cannot speak for the code as it is now, but I can help fix the problem.[1] The deployment wants to replace that symlink with a regular file which points at the local Unbound resolver and one additional upstream. But, at the same time it’s going to disable systemd-resolvd which owns that symlink above.
- systemctl disable --now systemd-resolved
- rm /etc/resolv.conf
- echo “nameserver 9.9.9.9” > /etc/resolv.conf
This should be enough to allow the code to pick up on it’s tasks - it will mask the unit as well and provide it’s own file upload and add Unbound.
Code refernce, class UnboundDeployer: relay/cmdeploy/src/cmdeploy/deployers.py at main · chatmail/relay · GitHub
[1] my first thought is “I wonder if he has a dangling symlink and the new code can’t handle that?” - I’d look at ls -ld /run/systemd/resolve/stub-resolv.conf and see if that’s where the mysterious “File not found” error is originating. $0.02, guessing
This worked perfectly, thank you!
@missytake it would appear that the fix applied 2 days ago (Force=True) isn’t working; from the output above, this relay operator had that code in use (they’re one commit newer) but still ran into this problem. I’m guessing it’s because of an underlying pyinfra failure that Force doesn’t handle.
ref: fix: still overwrite /etc/resolv.conf if it is a symbolic link · chatmail/relay@ebf5a51 · GitHub
Based on my random learned knowledge (years of RHEL and Arch) even distro packages have this problem when trying to replace what was a symlink with what now is a regular file, it’s a niche area of systems level failure.
The easiest way in my mind is to remove it first )[[ -l /etc/resolv.conf ]] && rm /etc/resolve.conf) before the write operation, which is how I typically do it like in this help thread.