Updater expects AdGuard Home to be located in the working directory and with a hardcoded name

[ferferga]

Prerequisites

• [ ] I am running the latest version
• [X] I checked the documentation and found no answer
• [X] I checked to make sure that this issue has not already been filed
• [X] I know how to perform a manual upgrade process, but I would like to have the Web UI upgrade process working for an easier upgrade process

Issue Details

• Version of AdGuard Home server:
  • v0.107.2
• How did you install AdGuard Home:
  • Downloading the binary manually
• How did you setup DNS configuration:
  • DHCP config served by the same Raspberry Pi that hosts adguard using dnsmasq
• If it's a router or IoT, please write device model:
  • Raspberry Pi 4
• CPU architecture:
  • arm64
• Operating system and version:
  • Debian 11 Bullseye

Further details about my installation

Although AdGuard is a portable single binary file, I wanted to have it installed in my Pi in a way that complies the most with the FHS standard. So I placed the binary under /usr/bin/adguard, the config file under /etc/adguard/AdGuardHome.yml and the data in /var/lib/adguard. To run it as a service, I created a systemd configuration file:

[Unit]
Description=AdGuard Home: Network-level blocker
Before=nginx.service

[Service]
WorkingDirectory=/var/lib/adguard
ExecStart=/usr/bin/adguard -c /etc/adguard/AdGuardHome.yaml -w .
Restart=always
RestartSec=5
TimeoutStartSec=10

[Install]
WantedBy=network-online.target systemd-resolved.target

Expected Behavior

When an update happens (such as my case, where I'm running v0.107.2 and v0.107.3 is released):

• Popup appears in the Web UI
• Press "Update now"
• AdGuard downloads the new updates and replaces the old binary with the new one
• AdGuard exits, leaving all the restart control to systemd or whatever service the user has configured. Users who are not running adguard as a service should expect that after an update, the old binary exits gracefully, as with almost everything else.

The whole process should work in the same way as rclone selfupdate, which knows where the binary is located (independently from the working dir) and that it's own name is rclone.

Actual Behavior

Update fails and verbose logging and query response for the /update endpoint states:

checking "AdGuardHome": stat AdGuardHome: no such file or directory

Additional context

In reality, this is a feature request

The binary should also have an argument that performs the self upgrade, so the upgrade process can also be performed automatically through bash and independently from web, without curl trickeries.

[ainar-g]

Hello and thank you for the report! I've split the feature request part into a separate issue. The current behaviour where AdGuard Home assumes that the name of its binary could probably be changed, but it needs to be done carefully.

[Mizzick]

@ferferga please check the new buildv0.108.0-a.161+77e5e27d, that has been just published to the edge channel.

[ainar-g]

We'll close this issue for now. Please feel free to report any new issues.

[ferferga]

Hello again!

This issue has not been fully resolved in v0.107.8 (as I saw that the fix has been backported to this version).

I tried updating to v0.107.9 using the autoupdater, but it still fails. Logs show the following output:

2022/08/05 09:33:21.576130 [info] updater: updating

2022/08/05 09:33:21.576410 [info] updater: finished; errors: checking "adguard": stat adguard: no such file or directory

2022/08/05 09:33:21.576480 [error] POST /control/update: checking "adguard": stat adguard: no such file or directory

The executable now recognises its name properly, but I guess it's trying to find himself in the working or config directory instead? (that's why it cant't find the file)

Refer to the original post to review the structure of the AdGuard installation in my system.

cc @ainar-g @Mizzick for reviewing/reopening the issue.

[Mizzick]

@ferferga hello again, please have an other look on just published edge build v0.108.0-a.258+c098960b.

[ainar-g]

Once again, feel free to reopen if this is still an issue.

[ferferga]

@ainar-g @Mizzick Although the issue has been closed, just wanted to chime in to confirm you that I tested an upgrade to v0.108.0-a.267+3c0d2a92 and it worked flawlessly!

Thank you very much for the work you do in this software!