SABnzbd Forums

Hi,

I have seen the other posts related to starting the daemon on Ubuntu 16.04 and that legacy support allows it to function the same way it was working from /etc/init.d.

Unfortunately, my brand new install of Ubuntu 16.04.1, and adding the repository for sabnzbd is not working.

I have edited the /etc/default/sabnzbdplus file to add a username. But when starting the daemon it fails stating that it is not activated and please edit the /etc/default/sabnzbdplus file, which I have edited.

I have even gone so far as to remove the /etc/init.d components and create a systemd configuration. It has the same results. I have reformatted and installed 14.04 because I know it works but I want 16.04, so I reformatted again and reinstall a fresh 16.04 with the same results.

There are no useful log entries to post. syslog says it started and systemctl reports it active(exited) with the error, please edit /etc/default/sabnzbdplus

Suggestions?

And now it is working. Sorry to bother you.

Here is what I had to do, not sure why, but it did work.

sudo systemctl disable sabnzbdplus
sudo systemctl enable sabnzbdplus
sudo /etc/init.d/sabnzbdplus start

The only thing that I can think of is because the systemctl status appeared to be unchanged since the first time I started the service which was probably before I remembered to edit the /etc/default/sabnzbdplus file to add a user. All of my attempts to stop and restart the service after editing the file appear to have not applied because I noticed this detail of the systemctl status sabnzbdplus command:

sudo systemctl status sabnzbdplus.service
● sabnzbdplus.service - LSB: SABnzbd+ binary newsgrabber
Loaded: loaded (/etc/init.d/sabnzbdplus; bad; vendor preset: enabled)
Active: active (exited) since Tue 2016-08-02 14:42:10 CDT; 18h ago
Docs: man:systemd-sysv-generator(8)

Even though I had tried to stop the service and restart it many times since 8-02 14:42, the systemctl status still showed a status as of 18h ago, which was not accurate.

Disabling this legacy service and re-enabling the legacy service appears to have functioned similar to doing a systemctl daemon-reload for systemd services.