Re: Why does resolv.conf keep changing?
On Wed, Oct 25, 2017 at 09:24:49AM -0400, Stefan Monnier wrote:
> > I am not willing to accept
> And what are you going to do about that? Sue us? Sue Debian Inc. ?
Whoa. Take it down a notch. Considering I am a member of the project
itself it would be very counterproductive for me to to have a toxic
attitude towards it.
> > that there is no way to identify what is going on that is causing
> > resolv.conf to change.
I was simply offering a rationale for why I did not find it appropriate
to implement your "solution" yet. As an engineer, I think it important
to understand the root cause of a problem before proceeding with a
solution, else the solution may not be a good one.
Perhaps a better way for me to state it would have been, "I am not ready
to give up on investigating what is causing resolv.conf to change
unexpectedly. I would like to understand that before trying to solve
the problem in potentially the wrong way."
> BTW, maybe one way to identify the culprit is:
> - install resolvconf [ I know it sounds bad, but bear with me ].
> - add a script in /etc/resolvconf/update.d, e.g.:
> % cat >/etc/resolvconf/update.d/sm-tracker
> (date; ps -ef --forest) >>/var/log/sm-tracker.log
> % chmod +x /etc/resolvconf/update.d/sm-tracker
> - let your system run for a while and when resolv.conf changed,
> look at /var/log/sm-tracker.log to see what process called resolvconf
> to update /etc/resolv.conf
> You can uninstall resolvconf once you've found the culprit. Of course,
> this will only work if the culprit has been updated to make use of
> resolvconf when installed, but that should hopefully be the case.
Now, this is a good suggestion. As it happens, I have already
identified the culprit by stumbling upon temporary files it littered in
/etc, but had I not yet done that this would be a logical next step.
Even more because the inotify suggestion did not pan out and even incron
did not show who was changing resolv.conf.
Roberto C. Sánchez