CPU pinned when using eth + wifi #685
Description
Is there already an issue for your problem?
- I have checked older issues, open and closed
NZBGet Version
v25.3-stable
Platform
Linux/Docker
Environment
NixOS 25.05, using the nixpkgs-packaged nzbget 25.3.
Computer is connected to internet via wifi AND ethernet, with (I think) wifi the default interface.Current Behavior
nzbget is spinning (taking up a constant ~4% cpu usage on my system), not doing anything (not responding to any rpc requests), and producing no logs.
Expected Behavior
It should just work like normal.
Steps To Reproduce
- Startup nzbget while connected to both wifi and ethernet networks on linux
Logs
from journalctl -xeu nzbget:
Nov 02 21:30:30 alaraph systemd[1]: Starting NZBGet Daemon...
░░ Subject: A start job for unit nzbget.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit nzbget.service has begun execution.
░░
░░ The job identifier is 111.
Nov 02 21:30:30 alaraph systemd[1]: Started NZBGet Daemon.
░░ Subject: A start job for unit nzbget.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit nzbget.service has finished successfully.
░░
░░ The job identifier is 111.
Nov 02 21:30:30 alaraph nzbget[1462]: [INFO] nzbget 25.3 server-mode
Nov 02 21:30:30 alaraph nzbget[1462]: [INFO] using /var/lib/nzbget/nzbget.conf
Nov 02 21:30:30 alaraph nzbget[1462]: [INFO] nzbget runs on 0.0.0.0:6789
I'm using the default config file.
I use nzbget through a systemd service, the ExecStart line of which is:
/nix/store/y84mllnvara3y23bh97q2z17fyllwjfl-nzbget-25.3/bin/nzbget --server --configfile /var/lib/nzbget/nzbget.conf -o ArticleCache=100 -o ConfigTemplate=/nix/store/y84mllnvara3y23bh97q2z17fyllwjfl-nzbget-25.3/share/nzbget/nzbget.conf -o ControlPassword= -o ControlUsername= -o CursesTime=yes -o DestDir=/media/downloads/nzbget -o DetailTarget=screen -o DiskSpace=2000 -o ErrorTarget=screen -o InfoTarget=screen -o OutputMode=loggable -o PostStrategy=rocket -o RenameIgnoreExt=.zip, .7z, .rar, .gz, .par2 -o Server1.Active=no -o SevenZipCmd=/nix/store/rfsfnzba419k4vrdyqggbs9kf9nv7nrs-p7zip-17.06 -o UnrarCmd=/nix/store/p64bz5i9y73ix81r4p61knka180z5gps-unrar-7.1.10 -o UpdateCheck=none -o UrlConnections=10 -o WarningTarget=screen -o WebDir=/nix/store/y84mllnvara3y23bh97q2z17fyllwjfl-nzbget-25.3/share/nzbget/webui -o WriteBuffer=1024 -o WriteLog=none
but this issue exists even if I launch it without any config options.
Connecting to the process via gdb and running bt all produces:
(gdb) bt all
No symbol table is loaded. Use the "file" command.
(gdb) bt
#0 0x00007efdbf697389 in __futex_abstimed_wait_common ()
from /nix/store/daamdpmaz2vjvna55ccrc30qw3qb8h6d-glibc-2.40-66/lib/libc.so.6
#1 0x00007efdbf699e1e in pthread_cond_wait@@GLIBC_2.3.2 ()
from /nix/store/daamdpmaz2vjvna55ccrc30qw3qb8h6d-glibc-2.40-66/lib/libc.so.6
#2 0x000056118ca84b3b in ?? ()
#3 0x000056118ca8803b in ?? ()
#4 0x000056118ca880fd in ?? ()
#5 0x000056118ca12625 in ?? ()
#6 0x00007efdbf62a4d8 in __libc_start_call_main ()
from /nix/store/daamdpmaz2vjvna55ccrc30qw3qb8h6d-glibc-2.40-66/lib/libc.so.6
#7 0x00007efdbf62a59b in __libc_start_main_impl ()
from /nix/store/daamdpmaz2vjvna55ccrc30qw3qb8h6d-glibc-2.40-66/lib/libc.so.6
#8 0x000056118ca1b705 in ?? ()
If this issue isn't easily solvable, I could try compiling a debug version and looking at the backtrace on that instead.
Extra information
I noticed this behavior on an arch linux computer as well, also when it was connected to both ethernet and wifi.
I'm fairly confident that it's due to the combination of wifi and ethernet since it was working just fine on this computer until I plugged it into ethernet. I shut down the computer while nzbget was running fine, moved it to a different spot in the house, plugged it into ethernet (while previously it was just using wifi), and started it up again. Immediately, nzbget starts exhibiting this issue.
As a sidenote, I think a nice addition to nzbget that might function as a workaround to this issue would be the addition of a configuration parameter to specify the network interface to use - that way I can ensure I have the best speeds with my ethernet connection.