Doing /etc/init.d/nzbget start does NOT start the daemon, contrary to what it says. No daemon is started. Starting it manually, say with: nzbget --configfile /etc/nzbget.conf --daemon works fine. Reason ------ Typing what the init script does: start-stop-daemon --start --user nzbstart --group nzbget --exec /usr/bin/nzbget -- --configfile /etc/nzbget.conf --daemon has also no effect. This indicates some problem between start-stop-daemon and nzbget. Workaround ---------- Start the daemon manually as above. Some info ========= Portage 2.2.28 (python 3.4.3-final-0, hardened/linux/x86, gcc-4.9.3, glibc-2.22-r4, 3.18.25-gentoo-r1 i686) ================================================================= System uname: Linux-3.18.25-gentoo-r1-i686-Intel-R-_Pentium-R-_4_CPU_3.40GHz-with-gentoo-2.2 KiB Mem: XXX total, 156540 free KiB Swap: YYY total, 2251108 free Timestamp of repository gentoo: Mon, 10 Oct 2016 14:15:01 +0000 sh bash 4.3_p48 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p48::gentoo dev-java/java-config: 2.2.0-r3::gentoo dev-lang/perl: 5.22.2::gentoo dev-lang/python: 2.7.10-r1::gentoo, 3.4.3-r1::gentoo dev-util/cmake: 3.5.2-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.19.1::gentoo sys-apps/sandbox: 2.10-r2::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.4_p6-r2::gentoo, 1.5-r2::gentoo, 1.6.3-r2::gentoo, 1.7.9-r3::gentoo, 1.8.5-r5::gentoo, 1.9.6-r4::gentoo, 1.10.3-r1::gentoo, 1.11.6-r1::gentoo, 1.12.6::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.24-r3::gentoo, 2.25.1-r1::gentoo sys-devel/gcc: 4.3.6-r1::gentoo, 4.4.7::gentoo, 4.8.5::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.22-r4::gentoo
You've changed your local configuration from the default: - You're using /etc/nzbget.conf and not the default /etc/nzbgetd.conf - You're using another username than the default one - I don't see when you're manually starting if you are using the correct user I suspect you're starting directly as root, which creates some sort of permission problem for the init script case, if DaemonUsername is not correctly set in nzbget.conf
It is my right to use whichever config file I like. Options and choices are there in order to be used. I don't like having to use two different configuration files for the same program, so I have configured to use nzbget.conf for the daemon too. This is set in my /etc/conf.d/nzbget where I have deliberately set: NZBGET_CONFIGFILE="/etc/nzbget.conf" This is totally legal and should be observed by the init scripts, including start-stop-daemon. On the command-line, I already showed that I use the (also totally legal) option -configfile /etc/nzbget.conf That's about your first observation. About the other two ones regarding the user that starts the init scripts: init scripts are (usually) executed during boot by root. What does this have to do with the user they change to, if they are configured to do so? Example: the init script for the Apache web server is started (usually) by root. The Apache server itself is configured to change to some other user (like 'www'), but that's irrelevant to the init script. The same should be possible with nzbget: the init script may (should) be started by root, but nzbget itself switches to the user configured in the config file(s). I thus must confess that I don't get what you are trying to tell me with your other two points... It looks like a misunderstanding, so let me be clear about my expectations: When I start the daemon with the init script and explicitly tell it to use a different config file, then I expect it to use *that* file. When I set a user/group with NZBGET_USER NZBGET_GROUP in the config file I told it to use, then I expect the daemon to switch to that user/group *after* it starts. I still expect to be able to start *any* init script (including nzbget's) as root *without* any permission problems. I don't think I expect too much...
