How to identifiy what is changing config file content on reboot?

Hello,

I’m having a very strange situation here and before putting the blame on anyone, I would like to identify the source of my issue.

I have installed a package that has its default configuration files but that I have further configured via additional files in /etc/packagename.d/ named like this:

97-firstextraconfig.conf
98-secondextraconfig.conf
99-thirdextraconfig.conf

The options in there are properly taken into account when I restart the daemon after having made changes in any of those three files.
I can restart the service with systemctl as many times as I want, the content of those files is not modified and the parameters are taken into account just fine.

Now, if I reboot the entire machine, the contents of the second file get overwritten by the contents of the first file! Yes, you read that right, it’s only happening upon reboot, not when I stop/start the service myself.
Fortunately, each file is just one line, so it’s easy to restore the content, but I’d really like to figure out where this change is coming from.

Do you have any suggestion as to where I should look? Could it be in the .service file that it is processing a special value upon reboot?

What do you suggest I try to identify the source of those changes upon reboot?

I would imagine it’s in the startup process of the app, probably not the service file, but I’d certainly start by checking the service file just to be certain.

Have you looked through the application documentation? I ask, because that seems like it’s going to be application specific, and it’s something that might be easily triggered because of the names of the config files or some kind of default app startup behavior.

If it’s an open source project I’d definitely check their bugs/issues on GitHub or where ever the project does their work.

This is a weird case. No sane application modifies their own config files. Also, they shouldn’t be able to because /etc is owned by root.

You could mark the files read-only (chattr +i) and see if that helps or which other service fails because of this.

It would help if you tell us which program that is but if it’s a secret, we can’t know anything for sure.

1 Like

Yes, and nothing came up here. Also there is nothing in the issue tracker.

Thanks, I did not think of that.

I don’t mind telling you, it’s just that I’d rather not put the blame on them when it could definitely be my own doing.
That being said, it’s the config files for dnsmasq.d as provided and installed by the pihole-FTL AUR package.
I have asked the project questions in the past and it was made very clear that they would not even consider any issue reported by me because I’m not running the “standard” package.

What I’m doing is that I want dnsmasq to listen on two interfaces, which I managed to do by having those two config files:

97-pihole-wlp0.conf

interface=wlp0

98-pihole-enp2s1.conf

interface=enp2s1

This works just fine but as I said, upon reboot, the 98-pihole-enp2s1.conf file sees its content replaced with the one from 97-pihole-wlp0.conf. This means dnsmasq no longer listen on both interfaces with the consequences you can imagine.

Reasonable.

Don’t be so fscking squirrely/secretive. Post the contents of those 2 .conf files (I’m willing to bet that you are not quite grasping what/how lexical ordering works).

You already have them, it’s one line only in both of them.

… after reboot
the contents of both files are identical
with both containing
interface=wlp0
?

Whereas before the reboot they where different?

No program I know of,
reads it’s config files
and then proceeds to alter them.
… all by itself …

To read it’s configuration from a directory containing multiple files
it has to be started with the:
-7, --conf-dir=<directory>[,<file-extension>......]
option
which needs user intervention - it’s not a default, AFAIK

otherwise it will only read from:

/etc/dnsmasq.conf

-7, --conf-dir=<directory>[,<file-extension>......],
              Read all the files in the given directory as configuration files. If extension(s) are given, any files which end in those extensions are skipped.  Any
              files  whose names end in ~ or start with . or start and end with # are always skipped. If the extension starts with * then only files which have that
              extension are loaded. So --conf-dir=/path/to/dir,*.conf loads all files with the suffix .conf in /path/to/dir. This flag may be given on  the  command
              line or in a configuration file. If giving it on the command line, be sure to escape * characters. Files are loaded in alphabetical order of filename.

Something else is going on here.

Yes, exactly.

I agree, there is something fishy here, but I’m yet to find what it is

… read further - reading the configuration from multiple files in a config directory requires user intervention … it is not the default behaviour

… if this program overwrites/alters/adjusts it’s own configuration files …
all bets are off, as they say
I’d wager a couple of thousand € that that is not the case
not with that program installed from trusted source …

I’d rather bet against you - or, in other words, for you, having made some mistake :wink:
(no offense implied - please!)

None taken, that’s definitely what I think, but I can’t figure out (yet) what I’ve done wrong

what I don’t know is:
is
/etc/dnsmasq.conf

still applied

when the program is started with:
-7
or
--conf-dir=...

maybe check that (standard) config file
and your way of starting dnsmasq
because, using:
--conf-dir=...
is not default behaviour

Why file contents in your designated configuration directory might change
is beyond me. I have no idea how to begin to troubleshoot this.
Look at the access time, modification time … and the system logs … for clues.

If you don’t start dnsmasq with the
--conf-dir=...
option
what is in those files should not matter anyway
as
/etc/dnsmasq.conf
is being used.

You could define your two interfaces there.

This thread is turning into a train-wreck.

@obones:

  1. What are you trying to do/accomplish?

  2. Are you actually running a pi-hole on this particular machine? If you are, then you would know that you don’t run dnsmasq stand-alone - it conflicts wth pi-hole’s fork of dnsmasq.

1 Like

This seems like an “error” in the logical setup of pihole. It is not supposed to have those files modified by the user.
The whole setup of pihole is a bit strange because the target audience is actually raspberry pi users with the only purpose running pihole.

Read the configuration of pihole. There is one file where you can add custom settings. I don’t remember but it is there.

I suggest using pihole from docker which does work out-of-box (batteries not included).

I’m trying to figure out what is modifying a config file behind my back, on an otherwise perfectly working pi-hole installation from the AUR.
Yes, I know pi-hole uses its own dnsmasq installation and it is the one that I’m configuring here. I did not install the dnsmasq package form Manjaro, the files in /etc/dnsmasq.d/ all come from the pi-hole-ftl package itself

Except that when you want it to listen on two interfaces, it is said to use the dnsmasq configuration directly.

Now, maybe that’s that “one file for all” from pi-hole that is overwriting my custom config files.

Well, that adds another layer in there to go into when something goes wrong. And I want the DNS server to start as early as possible, placing it in Docker means another delay that is not that desirable.
And frankly, the configuration works, it’s just that something is thrashing it upon reboot.

Sure, my suggestion is only a workaround.

1 Like

I disagree.
I just installed it (from AUR) and started it - as it was. No configuration done at all.
neither /etc/dnsmasq.d/
nor any files within it exist.

Strange, at least 01-pihole.conf should be there. But then maybe it only appears after some settings have been changed as indicated in the manual.

Sorry if my message did not came out as nice as it should have been, it’s not meant to aggravate you in any kind of way. But maybe the (perceived) animosity from other messages got into me after all.

Well, I finally found a way to figure out what part of my system is modifying that file, thanks to the audit service and an appropriate watch.
And in the end, I was right from the beginning, it’s a script of mine that was doing this, one that I installed in /etc/NetworkManager/dispatcher.d/ which reacts to interfaces coming up and down. For some reason only known to the “me” from too many months ago, I decided it would be fine to change other services config on the fly. And of course I made a mistake and always changed the same file instead of only the one that is meant for a given interface.

After having fixed this, it’s now behaving more logically