←back to thread

134 points todsacerdoti | 1 comments | | HN request time: 0s | source
Show context
johnisgood ◴[] No.44602632[source]
It is not the same, but I do use "chattr +i" on a file (which applies the immutable attribute) on Linux to a file that otherwise would have been overwritten by programs that do not give a damn whether I want it to or not, and in my case it was easier to just make that file immutable, mainly: /etc/resolv.conf.
replies(3): >>44602842 #>>44603152 #>>44604893 #
knorker[dead post] ◴[] No.44602842[source]
[flagged]
johnisgood ◴[] No.44602873[source]
That actually does not sound too far-fetched. I believe there is a high chance that it might eventually happen, at least to files systemd """cares""" about.
replies(1): >>44604284 #
JdeBP ◴[] No.44604284[source]
In reality, this is something that people have been doing to systemd-resolved in desperation since the late 2010s (e.g. https://unix.stackexchange.com/q/421977/5132 for one of many examples), and systemd has not been changed in all of that time to undo this.

It is actually an unnecessary act of desperation, as systemd does have a way of setting things up so that /etc/resolv.conf is entirely manually configured. It's just (a) not completely obvious to deduce from the systemd doco, and (b) something that gets the blame for things that actually lie elsewhere in the system that also need disconnection, like /etc/nsswitch.conf giving nss-resolve priority over nss-dns.

That that situation remains the case today (five years after I wrote https://unix.stackexchange.com/a/612434/5132 for example, and almost a decade since the desperate making resolv.conf immutable idea took off) is a good indicator that the systemd developers aren't in reality in any hurry to force some hypothetical total ownership of /etc/resolv.conf by systemd.

replies(2): >>44604643 #>>44604955 #
johnisgood ◴[] No.44604643[source]
The system on which I am using "chattr +i" is not even a systemd one. I forgot why I set the attribute in the first place. I might be able to figure it out, but it was the simplest and least time-consuming yet effective solution at the time. I think there were more than one reasons for it.
replies(1): >>44604896 #
JdeBP ◴[] No.44604896{3}[source]
My educated guess would be either NetworkManager or resolveconf (or a DHCP client not even going through resolvconf), with fun with package upgrades resetting customizations as my second choice educated guess. (-:
replies(2): >>44605174 #>>44605656 #
1. johnisgood ◴[] No.44605656{4}[source]
I think the reason was resolveconf and package updates, yes.