Symbolic links to config YAML are replaced by a copy of the real file by AGH after startup

[knaggsy2000]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to report a bug and not ask a question or ask for help

• I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

FreeBSD, ARM64

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

v0.107.44

Action

cd /opt/AdGuardHome
ln -s AdGuardHome.yaml.mytestconfig AdGuardHome.yaml

All while the service is stopped.

Expected result

I expect to see the symbolic link honoured and not messed around with.

Actual result

AGH after startup, removes the symbolic link and replaces it with a copy of the actual file.

This is not normal behaviour for a application.

Additional information and/or screenshots

As currently testing versions of AGH with a previously mentioned issue, noticed this strange behaviour.

[piyushgarg]

This is a regression in recent builds. It was working earlier as expected.

[knaggsy2000]

So when can I expect it to work correctly then?

[ainar-g]

@knaggsy2000, I cannot reproduce this. Is your AGH installed as a service? If so, did you use AdGuardHome -s install?

[knaggsy2000]

@ainar-g Yes, it was installed as a service by the AGH script.

Also noticed something that the script needed the sudo package to be installed but it shouldn't need it (as installed by root) - should I raise this as bug?

Just re-tested with v0.107.44 on a Raspberry Pi 3 running FreeBSD 14.0-RELEASE-p3: -

# pwd
/opt/AdGuardHome

# ll
total 29168
-rwxr-xr-x 1 root wheel 29622272 Feb 8 23:34 AdGuardHome*
-rw-rw-rw- 1 root wheel 587 Feb 8 23:34 AdGuardHome.sig
lrwxr-xr-x 1 root wheel 27 Feb 15 23:15 AdGuardHome.yaml@ -> AdGuardHome.yaml.ipsdefined
-rw-r--r-- 1 root wheel 12236 Feb 8 23:43 AdGuardHome.yaml.all
-rw-r--r-- 1 root wheel 12344 Feb 8 23:41 AdGuardHome.yaml.ipsdefined
-rw-r--r-- 1 root wheel 106840 Feb 8 23:34 CHANGELOG.md
-rw-r--r-- 1 root wheel 35149 Feb 8 23:34 LICENSE.txt
-rw-r--r-- 1 root wheel 22187 Feb 8 23:34 README.md
drwxr-xr-x 2 root wheel 512 Feb 8 23:34 agh-backup/
drwxr-xr-x 3 root wheel 512 Feb 12 09:20 data/

# /opt/AdGuardHome/AdGuardHome -s start
2024/02/15 23:16:15 [info] AdGuard Home, version v0.107.44
2024/02/15 23:16:15 [info] service: control action: start
2024/02/15 23:16:15 [info] service: action start has been done successfully on freebsd

# ll
total 29184
-rwxr-xr-x 1 root wheel 29622272 Feb 8 23:34 AdGuardHome*
-rw-rw-rw- 1 root wheel 587 Feb 8 23:34 AdGuardHome.sig
-rw-r--r-- 1 root wheel 12344 Feb 15 23:16 AdGuardHome.yaml
-rw-r--r-- 1 root wheel 12236 Feb 8 23:43 AdGuardHome.yaml.all
-rw-r--r-- 1 root wheel 12344 Feb 8 23:41 AdGuardHome.yaml.ipsdefined
-rw-r--r-- 1 root wheel 106840 Feb 8 23:34 CHANGELOG.md
-rw-r--r-- 1 root wheel 35149 Feb 8 23:34 LICENSE.txt
-rw-r--r-- 1 root wheel 22187 Feb 8 23:34 README.md
drwxr-xr-x 2 root wheel 512 Feb 8 23:34 agh-backup/
drwxr-xr-x 3 root wheel 512 Feb 12 09:20 data/

Yep, the symbolic link is getting removed by the AGH service and replaced with a copy of the actual file.

[knaggsy2000]

@piyushgarg Can you provide any additional info?

[ainar-g]

@knaggsy2000, can you enable verbose logs for your AGH service? That should shed light on what's going on.

[piyushgarg]

@knaggsy2000 I might be wrong, it is deleting the link and then creating a new file.

2024/02/18 22:57:32.482699 1518#1 [info] AdGuard Home, version v0.107.44
2024/02/18 22:57:32.482821 1518#1 [debug] current working directory is /opt/AdGuardHome
2024/02/18 22:57:32.482949 1518#1 [debug] reading config file: /home/pi/.config/agh/AdGuardHome.yaml
2024/02/18 22:57:32.485580 1518#1 [debug] got schema version 28
.....
2024/02/18 22:57:32.492988 1518#38 [debug] clients: removed 0 client aliases
2024/02/18 22:57:32.493099 1518#38 [debug] clients: adding client info 127.0.0.1 -> "etc/hosts" "localhost" [1]
2024/02/18 22:57:32.493149 1518#38 [debug] clients: adding client info ::1 -> "etc/hosts" "localhost" [2]
2024/02/18 22:57:32.493188 1518#38 [debug] clients: adding client info 127.0.1.1 -> "etc/hosts" "piyush.localdomain" [3]
2024/02/18 22:57:32.493215 1518#38 [debug] clients: added 3 client aliases from system hosts file
2024/02/18 22:57:32.493342 1518#1 [debug] writing config file "/home/pi/.config/agh/AdGuardHome.yaml"
2024/02/18 22:57:32.500058 1518#1 [info] Initializing auth module: /opt/AdGuardHome/data/sessions.db

[knaggsy2000]

@piyushgarg Exactly, AGH is certainly messing with the symbolic link.

[knaggsy2000]

@ainar-g Yes, and see the same as @piyushgarg - AGH is saying it's "writing config file": -

2024/02/18 23:09:53.880773 58531#1 [info] AdGuard Home, version v0.107.44
2024/02/18 23:09:53.885112 58531#1 [debug] current working directory is /opt/AdGuardHome
2024/02/18 23:09:53.885440 58531#1 [debug] reading config file: /opt/AdGuardHome/AdGuardHome.yaml
2024/02/18 23:09:53.906303 58531#1 [debug] got schema version 28
2024/02/18 23:09:53.918713 58531#1 [info] tls: using default ciphers
2024/02/18 23:09:53.919371 58531#1 [debug] hosts container: starting
2024/02/18 23:09:53.919635 58531#1 [debug] hosts container: refreshing
2024/02/18 23:09:53.923088 58531#1 [debug] hosts container: sending upd
2024/02/18 23:09:53.935517 58531#1 [debug] filtering: initialized 110 services
2024/02/18 23:09:53.943862 58531#1 [info] safesearch default: disabled
2024/02/18 23:09:53.948192 58531#1 [debug] dhcpd: warning: creating dhcpv4 srv: dhcpv4: invalid IP is not an IPv4 address
2024/02/18 23:09:53.950674 58531#39 [debug] clients: removed 0 client aliases
2024/02/18 23:09:53.954942 58531#39 [debug] clients: adding client info ::1 -> "etc/hosts" "localhost" [1]
2024/02/18 23:09:53.955209 58531#39 [debug] clients: adding client info 127.0.0.1 -> "etc/hosts" "localhost" [2]
2024/02/18 23:09:53.955359 58531#39 [debug] clients: added 2 client aliases from system hosts file
2024/02/18 23:09:53.955704 58531#1 [debug] writing config file "/opt/AdGuardHome/AdGuardHome.yaml"

I can understand why you would re-write the setting file (to ensure it's updated) but removing the symbolic link - that's not right. But at the same time, it is easier to simply remove the "old" file and replace it with the "new" one, done this myself. But you need to check if it's an symbolic link and actually resolve where that link goes.

[ainar-g]

As mentioned, this isn't what's supposed to happen, so you don't need to convince anyone, heh. Thanks for the logs, we'll try to investigate, what could be happening here.

[ainar-g]

@knaggsy2000, we weren't able to reproduce that on any of our configurations, so we've pushed a change that adds more debug logs to the configuration-file management methods. Can you please check out the latest builds on the Edge channels and collect the verbose logs? You can also send them to devteam@adguard.com with subject “AdGuard Home Issue 6717”.

[knaggsy2000]

@ainar-g Which OS'es/hardware did you test that with?

Now guessing how to do that, so I'll uninstall current version of my test PI: -

# fetch -o - https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v -u

So install edge version: -

# fetch -o - https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v -c edge
starting AdGuard Home installation script
channel: edge
operating system: freebsd
cpu type: arm64
AdGuard Home will be installed into /opt/AdGuardHome
checking tar
script is executed with root privileges
no need to uninstall
downloading package from https://static.adtidy.org/adguardhome/edge/AdGuardHome_freebsd_arm64.tar.gz -> AdGuardHome_freebsd_arm64.tar.gz
AdGuardHome_freebsd_arm64.tar.gz 9447 kB 7005 kBps 01s
successfully downloaded AdGuardHome_freebsd_arm64.tar.gz
unpacking package from AdGuardHome_freebsd_arm64.tar.gz into /opt
successfully unpacked, contents:
total 29004
-rwxrwxrwx 1 root wheel 29491200 Feb 21 14:12 AdGuardHome
-rw-rw-rw- 1 root wheel 587 Feb 21 14:12 AdGuardHome.sig
-rw-r--r-- 1 root wheel 108355 Feb 21 14:12 CHANGELOG.md
-rw-r--r-- 1 root wheel 35149 Feb 21 14:12 LICENSE.txt
-rw-r--r-- 1 root wheel 22300 Feb 21 14:12 README.md
2024/02/21 23:50:37 [info] AdGuard Home, version v0.108.0-a.848+9276afd7
2024/02/21 23:50:37 [info] service: control action: install
2024/02/21 23:50:37 [fatal] service: executing action "install": Failed to install AdGuard Home service: Init already exists: /usr/local/etc/rc.d/AdGuardHome
installation failed, removing /opt/AdGuardHome
cannot install AdGuardHome as a service

Hmmm, the uninstall script doesn't remove the init.d script - so had to remove that myself...

# rm /usr/local/etc/rc.d/AdGuardHome

I consider that a bug which needs to be addressed too - want me to raise that as a new issue?

Anyway, ran the install command again and now get this: -

starting AdGuard Home installation script
channel: edge
operating system: freebsd
cpu type: arm64
AdGuard Home will be installed into /opt/AdGuardHome
checking tar
script is executed with root privileges
no need to uninstall
downloading package from https://static.adtidy.org/adguardhome/edge/AdGuardHome_freebsd_arm64.tar.gz -> AdGuardHome_freebsd_arm64.tar.gz
AdGuardHome_freebsd_arm64.tar.gz 9447 kB 7539 kBps 01s
successfully downloaded AdGuardHome_freebsd_arm64.tar.gz
unpacking package from AdGuardHome_freebsd_arm64.tar.gz into /opt
successfully unpacked, contents:
total 29004
-rwxrwxrwx 1 root wheel 29491200 Feb 21 14:12 AdGuardHome
-rw-rw-rw- 1 root wheel 587 Feb 21 14:12 AdGuardHome.sig
-rw-r--r-- 1 root wheel 108355 Feb 21 14:12 CHANGELOG.md
-rw-r--r-- 1 root wheel 35149 Feb 21 14:12 LICENSE.txt
-rw-r--r-- 1 root wheel 22300 Feb 21 14:12 README.md
2024/02/21 23:51:34 [info] AdGuard Home, version v0.108.0-a.848+9276afd7
2024/02/21 23:51:34 [info] service: control action: install
2024/02/21 23:51:34 [info] service: started
2024/02/21 23:51:34 [info] Almost ready!
AdGuard Home is successfully installed and will automatically start on boot.
There are a few more things that must be configured before you can use it.
Click on the link below and follow the Installation Wizard steps to finish setup.
AdGuard Home is now available at the following addresses:
[SNIP!]
2024/02/21 23:51:34 [info] service: action install has been done successfully on freebsd
AdGuard Home is now installed and running
you can control the service status with the following commands:
sudo /opt/AdGuardHome/AdGuardHome -s start|stop|restart|status|install|uninstall

And that command last stated needs to change too. As for the installer to work you have to install the sudo pkg, but it's NOT actually needed for anything. I use "doas" instead of "sudo" as much lighter (especially in terms of code) and secure - please look into that too. Or would you prefer I raise another issue for that?

Also noticed that the uninstall script just wipes out /opt/AdGuardHome directory without any regard to any custom files/folders (as I see my test YAML file has been wiped out as well as the collected data). That is NOT good, especially on a FreeBSD system - as that's not good practice. Packages or ports, have to specifically define the files that they install so they can be removed safely, so any custom files/etc will be left behind - even the checksums get checked as to not remove any customised configs.

Going to save this comment now as it's getting long. Going to be more after this...

[knaggsy2000]

@ainar-g

As the uninstall wiped my custom files (which is wrong), need to set them up again...

# /opt/AdGuardHome/AdGuardHome -s stop

Then copied the YAML config to /opt/AdGuardHome/AdGuardHome.yaml and started the service again: -

# /opt/AdGuardHome/AdGuardHome -s start
2024/02/22 00:31:18 [info] AdGuard Home, version v0.108.0-a.848+9276afd7
2024/02/22 00:31:18 [info] service: control action: start
2024/02/22 00:31:18 [info] service: action start has been done successfully on freebsd

Checked the web interface and it's running, that's good - just more annoyed all of my stats have been wiped out :/

Using "drill" is returning DNS requests at least on the VLAN interface. Okay then, lets first test that symbolic link issue...

# ll
total 29024
-rwxrwxrwx 1 root wheel 29491200 Feb 21 14:12 AdGuardHome*
-rw-rw-rw- 1 root wheel 587 Feb 21 14:12 AdGuardHome.sig
lrwxr-xr-x 1 root wheel 20 Feb 22 00:41 AdGuardHome.yaml@ -> AdGuardHome.yaml.ips
-rw-r--r-- 1 root wheel 12400 Feb 22 00:31 AdGuardHome.yaml.ips

As you can see, I've just moved it over to a symbolic link.

Upon starting the service, get this in the log: -

2024/02/22 00:43:27.013100 54878#1 [info] AdGuard Home, version v0.108.0-a.848+9276afd7
2024/02/22 00:43:27.013718 54878#1 [debug] current working directory is /opt/AdGuardHome
2024/02/22 00:43:27.014191 54878#1 [debug] evaluating config path: lstat AdGuardHome.yaml: no such file or directory; using "AdGuardHome.yaml"
2024/02/22 00:43:27.014440 54878#1 [debug] reading config file "/opt/AdGuardHome/AdGuardHome.yaml"
2024/02/22 00:43:27.027772 54878#1 [debug] got schema version 28
2024/02/22 00:43:27.040340 54878#1 [info] tls: using default ciphers
2024/02/22 00:43:27.040982 54878#1 [debug] hosts container: starting
2024/02/22 00:43:27.041238 54878#1 [debug] hosts container: refreshing
2024/02/22 00:43:27.042163 54878#1 [debug] hosts container: sending upd
2024/02/22 00:43:27.061195 54878#1 [debug] filtering: initialized 111 services
2024/02/22 00:43:27.061810 54878#1 [info] safesearch default: disabled
2024/02/22 00:43:27.062242 54878#1 [debug] dhcpd: warning: creating dhcpv4 srv: dhcpv4: invalid IP is not an IPv4 address
2024/02/22 00:43:27.062788 54878#1 [debug] evaluating config path: lstat AdGuardHome.yaml: no such file or directory; using "AdGuardHome.yaml"
2024/02/22 00:43:27.062866 54878#13 [debug] clients: removed 0 client aliases
2024/02/22 00:43:27.062983 54878#1 [debug] using config path "/opt/AdGuardHome/AdGuardHome.yaml" for updater
2024/02/22 00:43:27.063196 54878#13 [debug] clients: adding client info ::1 -> "etc/hosts" "localhost" [1]
2024/02/22 00:43:27.063486 54878#13 [debug] clients: adding client info 127.0.0.1 -> "etc/hosts" "localhost" [2]
2024/02/22 00:43:27.063643 54878#13 [debug] clients: added 2 client aliases from system hosts file
2024/02/22 00:43:27.064004 54878#1 [debug] evaluating config path: lstat AdGuardHome.yaml: no such file or directory; using "AdGuardHome.yaml"
2024/02/22 00:43:27.064231 54878#1 [debug] writing config file "/opt/AdGuardHome/AdGuardHome.yaml"

What are those "lstat" messages? Is that the issue? As "lstat" is NOT a FreeBSD executable. I don't even know what that would do.

Running a "ll" now shows: -

-rwxrwxrwx 1 root wheel 29491200 Feb 21 14:12 AdGuardHome*
-rw-rw-rw- 1 root wheel 587 Feb 21 14:12 AdGuardHome.sig
-rw-r--r-- 1 root wheel 12400 Feb 22 00:43 AdGuardHome.yaml
-rw-r--r-- 1 root wheel 12400 Feb 22 00:31 AdGuardHome.yaml.ips

Symbolic link still messed around.

Numerous issues mentioned now.

[ainar-g]

Thanks for trying this out.

Regarding the script issues, hidden as off-topic

Hmmm, the uninstall script doesn't remove the init.d script - so had to remove that myself...

# rm /usr/local/etc/rc.d/AdGuardHome

I consider that a bug which needs to be addressed too - want me to raise that as a new issue?

Yes, please, file a separate one about this.

I use "doas" instead of "sudo" as much lighter (especially in terms of code) and secure - please look into that too. Or would you prefer I raise another issue for that?

Same. We use doas by default for OpenBSD, as you can see in the script itself, because it's just a convenience script that typically just assumes defaults, but I guess we could add a switch to override the default choice.

What are those "lstat" messages? Is that the issue? As "lstat" is NOT a FreeBSD executable. I don't even know what that would do.

It's not an excutable, but a syscall, see man 2 lstat. This error is returned when AGH evaluates the symlink to read/write the actual file. For some reason, on your system it gets an ENOENT. It could be some kind of wd weirdness, but it says that the working directory is /opt/AdGuardHome right above, so this is quite weird.

The two tests that should shed more light on the situation are:

1. Trying a symlink to an absolute path:

   ln -s "${PWD}/AdGuardHome.yaml.ips" AdGuardHome.yaml
   

2. Modifying the rc script to explicitly set the path to the symlink with -c ./AdGuardHome.yaml (see AdGuardHome --help as well as our Wiki article).

   (By the way, you can use the flag if the only reason for using a symlink is to use a different name for a config file.)

3. It's more of a question, really, but why are you using a soft link in the first place? If the actual configuration file is in the same directory a simple hard link should work just as well.

[knaggsy2000]

@ainar-g Separate issue raised about the init.d not being removed #6761

But what about the requirement of having to install sudo which it doesn't even use? Shall I raise that? Edit: I have - #6762

[knaggsy2000]

@ainar-g Ah, so "lstat" is a kernel call - I did think about that.

You mention that using "doas" is default for OpenBSD, so why doesn't the installer expect that? Given what I saw before.

[knaggsy2000]

Thanks for trying this out.
Regarding the script issues, hidden as off-topic

Hmmm, the uninstall script doesn't remove the init.d script - so had to remove that myself...
# rm /usr/local/etc/rc.d/AdGuardHome
I consider that a bug which needs to be addressed too - want me to raise that as a new issue?

Yes, please, file a separate one about this.

I use "doas" instead of "sudo" as much lighter (especially in terms of code) and secure - please look into that too. Or would you prefer I raise another issue for that?

Same. We use doas by default for OpenBSD, as you can see in the script itself, because it's just a convenience script that typically just assumes defaults, but I guess we could add a switch to override the default choice.

What are those "lstat" messages? Is that the issue? As "lstat" is NOT a FreeBSD executable. I don't even know what that would do.

It's not an excutable, but a syscall, see man 2 lstat. This error is returned when AGH evaluates the symlink to read/write the actual file. For some reason, on your system it gets an ENOENT. It could be some kind of wd weirdness, but it says that the working directory is /opt/AdGuardHome right above, so this is quite weird.

The two tests that should shed more light on the situation are:

1. Trying a symlink to an absolute path:
   ```shell
   ln -s "${PWD}/AdGuardHome.yaml.ips" AdGuardHome.yaml
   ```

2. Modifying the rc script to explicitly set the path to the symlink with `-c ./AdGuardHome.yaml` (see `AdGuardHome --help` as well as our Wiki article).
   (By the way, you can use the flag if the only reason for using a symlink is to use a different name for a config file.)

3. It's more of a question, really, but why are you using a soft link in the first place?  If the actual configuration file is in the same directory a simple hard link should work just as well.

# ln -s "${PWD}/AdGuardHome.yaml.ips" AdGuardHome.yaml
# ll
total 29024
-rwxrwxrwx  1 root wheel 29491200 Feb 21 14:12 AdGuardHome*
-rw-rw-rw-  1 root wheel      587 Feb 21 14:12 AdGuardHome.sig
lrwxr-xr-x  1 root wheel       37 Feb 23 00:03 AdGuardHome.yaml@ -> /opt/AdGuardHome/AdGuardHome.yaml.ips

# ee /usr/local/etc/rc.d/AdGuardHome 

Added "-c ./AdGuardHome.yaml" to the "command_args" to that file and now rebooting.

[knaggsy2000]

v0.108.0-a.858+36f9feca - still produced the same issue, but now see another update. Let me test one...

[knaggsy2000]

@ainar-g Yep, symbolic link is still destroyed and replaced with a copy of the file by AGH even with version v0.108.0-a.860+64090115.

[ainar-g]

The issue is still open, so we are aware that the issue still exists.

@Mizzick, please try to reproduce on a BSD system. We might need to add some more debug logs to see what goes wrong and when.

[Mizzick]

@ainar-g Indeed, I can reproduce the issue either with an absolute or relative path.

[knaggsy2000]

@Mizzick Thanks fellow BSD user. Not sure if this happens on a Linux OS too - guess they haven't noticed yet.

I look forward to v0.107.47 which shouldn't have the issue - when that is released I will re-test and provide feedback.

[Mizzick]

@knaggsy2000 please have a look, we have fixed it.

The new build version v0.108.0-a.874+7d9f33b2 has been just published to the edge channel.

[knaggsy2000]

@Mizzick Glad to see this so I updated the backup PI via the web interface (which is only on the edge channel) and tried the symbolic link again (while Adguard is stopped): -

# ll
total 29192
-rwxr-xr-x  1 root wheel 29622272 Apr  1 23:24 AdGuardHome*
-rw-rw-rw-  1 root wheel      566 Apr  1 23:24 AdGuardHome.sig
lrwxr-xr-x  1 root wheel       20 Apr  1 23:33 AdGuardHome.yaml@ -> AdGuardHome.yaml.ips
-rw-r--r--  1 root wheel    12509 Apr  1 23:30 AdGuardHome.yaml.ips

So starting up...

# /opt/AdGuardHome/AdGuardHome -s start
2024/04/01 23:34:00 [info] AdGuard Home, version v0.108.0-a.874+7d9f33b2
2024/04/01 23:34:00 [info] service: control action: start
2024/04/01 23:34:00 [info] service: action start has been done successfully on freebsd

Checking the symbolic link: -

# ll
total 29208
-rwxr-xr-x  1 root wheel 29622272 Apr  1 23:24 AdGuardHome*
-rw-rw-rw-  1 root wheel      566 Apr  1 23:24 AdGuardHome.sig
-rw-r--r--  1 root wheel    12509 Apr  1 23:34 AdGuardHome.yaml
-rw-r--r--  1 root wheel    12509 Apr  1 23:30 AdGuardHome.yaml.ips

Nope, it's STILL being destroyed and replaced by a copy of the original file.

I'm sad to say that the issue doesn't appear to be fixed - is there anything I can help with?

[Mizzick]

I guess this could be related to #2614.

@knaggsy2000 If you please check the contents of /usr/local/etc/rc.d/AdGuardHome?

[knaggsy2000]

@Mizzick I see that there's new versions for both the edge and stable - just updated those PIs to those. But I'm ONLY testing issues against the edge branch as to not wreck my network.

What do you want feedback on with that contents of that file?

[knaggsy2000]

@Mizzick

total 30056
-rwxr-xr-x  1 root wheel 30474402 Apr  5 21:50 AdGuardHome*
-rw-rw-rw-  1 root wheel      566 Apr  5 21:50 AdGuardHome.sig
lrwxr-xr-x  1 root wheel       20 Apr  5 21:57 AdGuardHome.yaml@ -> AdGuardHome.yaml.ips
-rw-r--r--  1 root wheel    12392 Apr  1 23:32 AdGuardHome.yaml.all
-rw-r--r--  1 root wheel    12509 Apr  1 23:30 AdGuardHome.yaml.ips

# /opt/AdGuardHome/AdGuardHome -s start
2024/04/05 21:57:58 [info] AdGuard Home, version v0.108.0-a.880+fd25dcac
2024/04/05 21:57:58 [info] service: control action: start
2024/04/05 21:57:58 [info] service: action start has been done successfully on freebsd

# ll
total 30072
-rwxr-xr-x  1 root wheel 30474402 Apr  5 21:50 AdGuardHome*
-rw-rw-rw-  1 root wheel      566 Apr  5 21:50 AdGuardHome.sig
-rw-r--r--  1 root wheel    12509 Apr  5 21:57 AdGuardHome.yaml
-rw-r--r--  1 root wheel    12392 Apr  1 23:32 AdGuardHome.yaml.all
-rw-r--r--  1 root wheel    12509 Apr  1 23:30 AdGuardHome.yaml.ips

Issue STILL stands on edge - v0.108.0-a.880+fd25dcac.

[Mizzick]

@Mizzick I see that there's new versions for both the edge and stable - just updated those PIs to those. But I'm ONLY testing issues against the edge branch as to not wreck my network.

What do you want feedback on with that contents of that file?

It actually contains the line with command_args:

command_args="-P ${pidfile} -p ${pidfile_child} -T ${name} -r {{.WorkingDirectory}}/{{.Name}}"

Please check that the working dir argument is correct, and also we might try to experiment with it.

[knaggsy2000]

@Mizzick Updated the edge PI to v0.108.0-a.883+ff7c715c.

Let me check that startup script (/usr/local/etc/rc.d/AdGuardHome): -

command_args="-P ${pidfile} -p ${pidfile_child} -T ${name} -r /opt/AdGuardHome/AdGuardHome -c ./AdGuardHome.yaml"

How is that looking?

[Mizzick]

@knaggsy2000 have you added -c ./AdGuardHome.yaml?
As we don't have it here.

[knaggsy2000]

@Mizzick Yes, as I mentioned. Issue still happens.

[Mizzick]

@Mizzick Yes, as I mentioned. Issue still happens.

You might try to use an absolute path, or remove -c ./AdGuardHome.yaml, as it works as default.

[Mizzick]

@knaggsy2000 and there is also the new build v0.108.0-a.891+60f48e2d, just published to the edge channel.

[knaggsy2000]

@Mizzick

1. Updated the test PI to that version
2. Removed the -c option from the rc.d script
3. Stopped the service
4. Removed the config file (as it previously was a copy)
5. "ln -s" to a config file
6. Started service

Oh well now - the symbolic link hasn't been removed, that's good news ^^.

When will this change be pushed to stable?

[knaggsy2000]

Once it reaches the stable branch, then this issue can be closed.

Thanks for all of your time.