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 > #!/bin/sh > (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. Regards, -Roberto -- Roberto C. Sánchez
