AdGuardHome doesn't know how to daemonize

deekerman commented

2026-03-04 02:04:39 -05:00

Owner

Originally created by @bbartlomiej on GitHub (Feb 17, 2021).

Originally assigned to: @ainar-g on GitHub.

Hi, I am using v0.104.3 and noticed that AdGuardHome can't actually go into background. There is no "-d" or "--daemon" switch available and the process always stays on the terminal in the foreground.
This is not a problem in linux with systemd but it is a problem in NetBSD where startup scripts are based on shell scripts.
FreeBSD works around this by invoking AdGuardHome through "daemon" binary which is available in base system.
I asked around and there is no such thing available in NetBSD base system so currently the startup script I wrote uses /usr/bin/sh "&" at the end of the command which of course is ugly.
Most (if not all?) daemons I saw have a -d flag or similar to go into background. Would it be possible to implement this in AdGuardHome?

PS. I managed to build AdGuardHome on NetBSD with no fuss at all and prepared a pkgsrc package (currently in wip/adguardhome).

Originally created by @bbartlomiej on GitHub (Feb 17, 2021). Originally assigned to: @ainar-g on GitHub. Hi, I am using v0.104.3 and noticed that AdGuardHome can't actually go into background. There is no "-d" or "--daemon" switch available and the process always stays on the terminal in the foreground. This is not a problem in linux with systemd but it is a problem in NetBSD where startup scripts are based on shell scripts. FreeBSD works around this by invoking AdGuardHome through "daemon" binary which is available in base system. I asked around and there is no such thing available in NetBSD base system so currently the startup script I wrote uses /usr/bin/sh "&" at the end of the command which of course is ugly. Most (if not all?) daemons I saw have a -d flag or similar to go into background. Would it be possible to implement this in AdGuardHome? PS. I managed to build AdGuardHome on NetBSD with no fuss at all and prepared a pkgsrc package (currently in wip/adguardhome).

deekerman added the

feature request

P3: Medium

research

labels

2026-03-04 02:04:39 -05:00

deekerman commented

2026-03-04 02:04:44 -05:00

Author

Owner

@ameshkov commented on GitHub (Feb 23, 2021):

Most (if not all?) daemons I saw have a -d flag or similar to go into background

Could you please list some examples? I don't fully understand what we should do with this flag.

@ameshkov commented on GitHub (Feb 23, 2021): > Most (if not all?) daemons I saw have a -d flag or similar to go into background Could you please list some examples? I don't fully understand what we should do with this flag.

deekerman commented

2026-03-04 02:04:44 -05:00

Author

Owner

@bbartlomiej commented on GitHub (Feb 23, 2021):

Sure. When you run ./AdGuardHome it stays on the foreground - other server-like software usually starts daemonized, in background, detached from terminal. Currently it is not possible to do with AdGuardHome. You can use Bash's "&" so ./AdGuardHome& but that is not a standard apporach to daemonize software. Some systems like FreeBSD have a "daemon" program which wraps around AdGuardHome and daemonizes it in the background. For Linux this is done by systemd.

Apache httpd - by default runs in background (as a daemon should) and you have -DFOREGROUND switch to prevent it from using setsid() and going into background. https://linux.die.net/man/8/httpd
Bind named DNS server - by default runs in background when started - as a daemon should. You have -f switch to keep it in foreground if you wish (mostly for debugging). https://man.netbsd.org/named.8
dhcpd - by default works in background as all server software. For debugging in foreground you have -f switch. https://bind9.net/dhcpd.8

So the request here is to make AdGuardHome a well behaved unix daemon. Servers (daemons) should run in background by default.
One option is to change default behavior and start daemonized, then you include "-f" flag to allow for foreground operation when needed for debugging.
Another option is to keep default behavior as is and add a "-d" flag to run it daemonized.

Regards,

@bbartlomiej commented on GitHub (Feb 23, 2021): Sure. When you run ./AdGuardHome it stays on the foreground - other server-like software usually starts daemonized, in background, detached from terminal. Currently it is not possible to do with AdGuardHome. You can use Bash's "&" so ./AdGuardHome& but that is not a standard apporach to daemonize software. Some systems like FreeBSD have a "daemon" program which wraps around AdGuardHome and daemonizes it in the background. For Linux this is done by systemd. Apache **httpd** - by default runs in background (as a daemon should) and you have -DFOREGROUND switch to prevent it from using setsid() and going into background. https://linux.die.net/man/8/httpd Bind **named** DNS server - by default runs in background when started - as a daemon should. You have -f switch to keep it in foreground if you wish (mostly for debugging). https://man.netbsd.org/named.8 **dhcpd** - by default works in background as all server software. For debugging in foreground you have -f switch. https://bind9.net/dhcpd.8 So the request here is to make AdGuardHome a well behaved unix daemon. Servers (daemons) should run in background by default. One option is to change default behavior and start daemonized, then you include "-f" flag to allow for foreground operation when needed for debugging. Another option is to keep default behavior as is and add a "-d" flag to run it daemonized. Regards,

deekerman commented

2026-03-04 02:04:44 -05:00

Author

Owner

@DENightOne commented on GitHub (Feb 24, 2021):

When I run "/opt/AdGuardHome/AdGuardHome -s start" it starts as daemon and runs in the background?
The output looks like this:
2021/02/24 09:48:27 [info] Service control action: start
2021/02/24 09:48:27 [info] Action start has been done successfully on linux-systemd
Its all documented here: [https://github.com/AdguardTeam/AdGuardHome/wiki/Getting-Started#service]

@DENightOne commented on GitHub (Feb 24, 2021): When I run "/opt/AdGuardHome/AdGuardHome -s start" it starts as daemon and runs in the background? The output looks like this: 2021/02/24 09:48:27 [info] Service control action: start 2021/02/24 09:48:27 [info] Action start has been done successfully on linux-systemd Its all documented here: [https://github.com/AdguardTeam/AdGuardHome/wiki/Getting-Started#service]

deekerman commented

2026-03-04 02:04:44 -05:00

Author

Owner

@bbartlomiej commented on GitHub (Feb 24, 2021):

DENightOne - I hope you recognize that you're talking about Linux with systemd (which still is not available everywhere) and I'm asking for being more portable, open and making life easier for non-systemd systems. In this case I'm talking about FreeBSD and NetBSD.
Well behaving Unix daemons run in background - if not by default, they have a command line switch for that. I gave examples in previous message.

@bbartlomiej commented on GitHub (Feb 24, 2021): DENightOne - I hope you recognize that you're talking about Linux with systemd (which still is not available everywhere) and I'm asking for being more portable, open and making life easier for non-systemd systems. In this case I'm talking about FreeBSD and NetBSD. Well behaving Unix daemons run in background - if not by default, they have a command line switch for that. I gave examples in previous message.

deekerman commented

2026-03-04 02:04:44 -05:00

Author

Owner

@DENightOne commented on GitHub (Feb 24, 2021):

Sorry I read your post quickly and missed you mentioning FreeBSD, was just trying to help

I have installed Adguard on PFSense and followed this writeup:
https://broadbandforum.co/t/205884/

I used the following to get it running:
Step 6: Making AdGuard Home start on boot:
Go to Services>shellcmd and click Add

Command: /usr/local/bin/screen -S AdGuardHome_screen -d -m /opt/AdGuardHome/AdGuardHome
Shellcmd Type: shellcmd
Description: AdGuard

This is run within pfsense but it is a shellcmd so it might help

@DENightOne commented on GitHub (Feb 24, 2021): Sorry I read your post quickly and missed you mentioning FreeBSD, was just trying to help I have installed Adguard on PFSense and followed this writeup: [https://broadbandforum.co/t/205884/](url) I used the following to get it running: Step 6: Making AdGuard Home start on boot: Go to Services>shellcmd and click Add Command: /usr/local/bin/screen -S AdGuardHome_screen -d -m /opt/AdGuardHome/AdGuardHome Shellcmd Type: shellcmd Description: AdGuard This is run within pfsense but it is a shellcmd so it might help

deekerman commented

2026-03-04 02:04:44 -05:00

Author

Owner

@bbartlomiej commented on GitHub (Feb 24, 2021):

Thanks, but this doesn't help with the problem described here. Even on NetBSD if I run it as is it will work on startup - because on startup there's no terminal to attach to. But then when you restart the service as root for example it will hijack your terminal and just stay there, lingering.
The reason you don't see a problem on PFSense is because you're not actually using the terminal, just the web gui. Oh and another workaround in there is starting AdGuardHome in a screen session - precisely to avoid the problem I'm describing here 😅

I'm asking for this because I discovered AdGuardHome as a great alternative to pi-hole. Pi-hole is Linux-only and here AdGuardHome excells. It's already a lot that it's portable and works on FreeBSD and NetBSD (and probably others with Go) without problems. Improving the daemonizing parts would help us on other systems even more.

PS. the script I created for NetBSD is this one:

 #!@RCD_SCRIPTS_SHELL@

# PROVIDE: lldpd
# REQUIRE: DAEMON
# BEFORE:  LOGIN

 . /etc/rc.subr

 name="adguardhome"
 rcvar="adguardhome"
 command="@PREFIX@/sbin/${name}"
 command_args="--no-check-update -c @PKG_SYSCONFDIR@/AdGuardHome.yaml -w @PREFIX@/libdata/adguardhome --pidfile @VARBASE@/run/${name}.pid -l syslog &"
 pidfile="/var/run/${name}.pid"

 load_rc_config $name
 run_rc_command "$1"

Those @VARBASE@, @PKG_SYSCONFDIR@ etc. macros are replaced with actual directories during package build. My workaround is to use "&" at the end of command but it's not elegant.

@bbartlomiej commented on GitHub (Feb 24, 2021): Thanks, but this doesn't help with the problem described here. Even on NetBSD if I run it as is it will work on startup - because on startup there's no terminal to attach to. But then when you restart the service as root for example it will hijack your terminal and just stay there, lingering. The reason you don't see a problem on PFSense is because you're not actually using the terminal, just the web gui. Oh and another workaround in there is starting AdGuardHome in a screen session - precisely to avoid the problem I'm describing here 😅 I'm asking for this because I discovered AdGuardHome as a great alternative to pi-hole. Pi-hole is Linux-only and here AdGuardHome excells. It's already a lot that it's portable and works on FreeBSD and NetBSD (and probably others with Go) without problems. Improving the daemonizing parts would help us on other systems even more. PS. the script I created for NetBSD is this one: ```bash #!@RCD_SCRIPTS_SHELL@ # PROVIDE: lldpd # REQUIRE: DAEMON # BEFORE: LOGIN . /etc/rc.subr name="adguardhome" rcvar="adguardhome" command="@PREFIX@/sbin/${name}" command_args="--no-check-update -c @PKG_SYSCONFDIR@/AdGuardHome.yaml -w @PREFIX@/libdata/adguardhome --pidfile @VARBASE@/run/${name}.pid -l syslog &" pidfile="/var/run/${name}.pid" load_rc_config $name run_rc_command "$1" ``` Those @VARBASE@, @PKG_SYSCONFDIR@ etc. macros are replaced with actual directories during package build. My workaround is to use "**&**" at the end of command but it's not elegant.

deekerman commented

2026-03-04 02:04:44 -05:00

Author

Owner

@ainar-g commented on GitHub (Feb 24, 2021):

Hi, we've researched the issue, and it seems like doing the “traditional” Unix daemonisation in a portable manner in Go is currently a bit tricky, due to issues regarding fork(2) and threads, goroutines, and other OS-related issues. In the rather old issue on that topic the basic recommendation is basically “use your init on startup and the & terminator in other cases”.

That doesn't mean that we won't attempt to do it, but we'll need more research and definitely more testing to make sure we aren't introducing subtle race conditions and low-level bugs.

@ainar-g commented on GitHub (Feb 24, 2021): Hi, we've researched the issue, and it seems like doing the “traditional” Unix daemonisation in a portable manner in Go is currently a bit tricky, due to issues regarding `fork(2)` and threads, goroutines, and other OS-related issues. In the rather old [issue] on that topic the basic recommendation is basically “use your `init` on startup and the `&` terminator in other cases”. That doesn't mean that we won't attempt to do it, but we'll need more research and definitely more testing to make sure we aren't introducing subtle race conditions and low-level bugs. [issue]: https://github.com/golang/go/issues/227

deekerman commented

2026-03-04 02:04:45 -05:00

Author

Owner

@bbartlomiej commented on GitHub (Feb 24, 2021):

I appreciate you made effort to look into this. I can help with tests on FreeBSD and NetBSD if needed.

@bbartlomiej commented on GitHub (Feb 24, 2021): I appreciate you made effort to look into this. I can help with tests on FreeBSD and NetBSD if needed.

deekerman referenced this issue

2026-03-04 02:36:48 -05:00

DNS rewrite of CNAME record does not follow upstream chain #2899

deekerman referenced this issue

2026-03-04 03:05:11 -05:00

dns rewrite checkbox #3148

deekerman referenced this issue

2026-03-04 03:07:39 -05:00

DNS rewrites outputting invalid addresses (manually having to use rewrites to bypass issue) #3171

deekerman referenced this issue

2026-03-04 03:23:05 -05:00

DNS Rewrite configuration #3302