If you're lazy, never do this. It's not very visible and you or someone else will lose hours troubleshooting it later.

Sometimes there's a point when you're just fed up with crap messing with your config and spending time hunting it down every other week to fix it and you just want it to stop.

I can think of no other cases where so many different tools write to the same single configuration file.

Also I'm not necessarily saying it's a good or a bad solution. But it works, so there's that.

Isn't that the quintessential lazy programmer solution? A quick hack that is beautiful but will cause lots of wasted time later.

Add a comment in the file?

as well as a `etc/resolv.conf.README_IMPORTANT`-file.

...that says "Beware of the Leopard".

Hours? If you have problems modifying a file as root on a writable medium, checking for immutability is probably the first thing to do.

I'm lazy, and I've been doing this on my own computers for over a decade. I wouldn't do it on a box that anyone else uses. And I've had to do the normal fixes for some VPN software when the network blackholes any DNS traffic not going to their server IPs. Otherwise it's worked out fine for me

That's why you leave yourself a comment reminding yourself what angry you did last week. :)

If you do it on every new system after OS install it's hard to forget.

Troubleshooting what?

For example why some daemon in the future takes lots of CPU spinning and logging errors about not being able to write to a file it's configured to manage.

I'll be grateful that it let me know it's stupid and can't fail gracefully.

Sound like exactly the kind of badly designed daemon I'd be trying to protect against by making the change in the first place

Let's be honest: Next to no service is designed to expect immutable files. At best they're handling a situation of read-only filesystems. If they document how configure not writing to a file and instead of doing that, the user is marking the file immutable, I wouldn't blame the app design.

Maybe someone later has some legitimate edit they want to make to the file, which fails because it's immutable, which is in turn very hard to figure out. (E.g., I didn't know that there exists an "immutable" attribute.)

Put a comment in the file with the exact commands to turn on and off immutability. This is just good practice for most things. Having a maintenance text file with all the system stuff is a secondary good practice along with the comment.

How long until SystemD and friends detect this and remove the immutable bit?

systemd-resolved explicitly (as in, it is documented behaviour) will not touch /etc/resolv.conf if it is a plain file.

It relies on /etc/resolv.conf being a symbolic link to it's generated version in /run/systemd/resolve/resolv.conf to do its thing. If it isn't linked, it assumes that is intentional and leaves your resolv.conf alone.

We'll use inotifywait then.

chattr (chflags on macos) - immutable files are a good defense against bad programs.

If you do that, do yourself a favor and put a comment line in resolv.conf telling your future self about it. :)

Won't that cause tons of errors in the services logs