Bug 602418 – net-nntp/sabnzbd-1.1.1-r1 init script reports sabnzbd failed to start when it actually did

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description James Chew 2016-12-12 08:32:49 UTC]

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

[Comment 1 Michał Kępień 2016-12-23 07:59:41 UTC]

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.

[Comment 2 James Chew 2016-12-26 13:21:48 UTC]

> 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.

[Comment 3 Michał Kępień 2016-12-27 07:34:49 UTC]

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.