On Mon 23 Oct 2017 at 19:33:01 (-0400), Roberto C. Sánchez wrote: > On Mon, Oct 23, 2017 at 11:25:05AM +0200, to...@tuxteam.de wrote: > > On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote: > > > On Sun, 22 Oct 2017 22:12:03 -0400 > > > Roberto C. Sánchez <robe...@debian.org> wrote: > > > > [...] > > > > > > I did find a page on the Debian wiki [0] which recommends setting the > > > > immutable attribute on /etc/resolv.conf. However, that feels like an > > > > ugly hack. > > > > > > > > > > It most certainly is, and shouldn't be necessary in your case. > > > > I've used that approach sometimes and regularly recommend it. > > > > That said, my main intention is to *debug* the problem, i.e. to > > provoke an error message in some log file or whatever, to learn which > > process is (undesirably?) mutating some file. Most of the time this > > leads to learning some config option to not do that mutation in the > > first place (or to some understanding on why that mutation is a Good > > Thing after all and to a better way of solving my real, underlying > > problem). > > > > Only in exceptional cases I had to "leave in" the immutable attribute > > as a permanent "solution". > > > > So, I edited resolv.conf to my preference and then made it immutable > with `chattr +i /etc/resolv.conf`. Several hours later the name server > was changed back to the ISP router's address. That is very odd. Yet > even more odd is that this time the domain and search options were left > untouched. Previously, the domain and search would get wiped (because > the ISP router doesn't push those options).
So if you: $ ls -l --full-time /etc/resolv.conf and then look at what happened at that precise time in /var/log/syslog or wherever your logs are being written. What took place? Cheers, David.
