I recently noticed this when I rebooted my headless server so I am unsure if it actually started from net-nntp/sabnzbd=1.1.1-r1 or earlier. The init script will report that valid pid file was not created, but it did and sabnzbd is running. Example when starting sabnzbd: # /etc/init.d/sabnzbd start * Starting SABnzbd ... * start-stop-daemon: did not create a valid pid in `/run/sabnzbd/sabnzbd [ !! ] * ERROR: sabnzbd failed to start Although the init script reported that the start failed, sabnzbd actually did start: # ps aux | grep sabnzbd sabnzbd 4859 2.2 0.1 1993656 58856 ? Sl 16:29 0:01 /usr/bin/python2.7 -OO /usr/share/sabnzbd/SABnzbd.py --config-file /etc/sabnzbd/sabnzbd.ini --logging 1 --daemon --pidfile /run/sabnzbd/sabnzbd.pid root 4968 0.0 0.0 10916 936 pts/0 S+ 16:30 0:00 grep --colour=auto sabnzbd And the PID file does contain the correct process id: # cat /run/sabnzbd/sabnzbd.pid 4859
Thanks for reporting, James. This is most likely caused by the fact that it took your SABnzbd+ instance more than one second to write the pidfile. SABnzbd+ does a lot of things before creating the pidfile, so it is perfectly understandable that under some circumstances it may take a while for the pidfile to be written to. If you happen to have a logfile from the time the problem occured, my guess would be that the difference in timestamps between lines "SABnzbd.py-1.1.1 (rev=...)" and "Starting SABnzbd.py-1.1.1" is more than one second. If you run into this problem on a regular basis, you can fix it by increasing the value of the --wait argument passed to start-stop-daemon in the init script. I do not see a way to solve this problem elegantly without reworking the way SABnzbd+ performs its startup. Justin, I do not think it is reasonable to increase this timeout for everyone because it would only cause longer startup times for most people without any real benefit. However, it might make sense to make this parameter configurable via conf.d. Let me know if you think this is a good idea and I might send a PR later.
> If you run into this problem on a regular basis, you can fix it by > increasing the value of the --wait argument passed to start-stop-daemon > in the init script. I do not see a way to solve this problem elegantly > without reworking the way SABnzbd+ performs its startup. Thanks Michał, I increased the --wait argument to 2000ms and it works now; but with the down side of having a slight delay there waiting for sabnzbd to start.
Using --wait is nothing but a fragile workaround for the issue at hand. If you do not use it, you risk a false positive (s-s-d reports success while the daemon exits with an error shortly after forking). If you do, you either risk a false negative (as described in your report) or you are forced to wait for a "safe" amount of time at each startup (as mentioned in your last comment). Again, there really is no way around this until upstream starts checking for errors before daemonizing.
