SABnzbd Forums

Would it be possible to have the --pid argument take the actual PID file to write to, rather than a folder?.

This is how most daemons work, so they will write the PID to the /var/run/sabnzbd.pid (or whatever you supply). This allows the same script to send the SIGTERM etc signals to the correct process. Currently, even if you specify a folder, you really don't know what the port will be from the sab configuration, so you don't know which process to send the SIGTERM too.

Every init script I see uses combinations of sed/awk to find the pid file, but that seems dangerous as their is always a chance you will find the wrong (if multiple exist) version of sabnzbd. Writing the pid to the supplied file would mean you know which pid is this process you started.

I think it would also cleanup the init scripts floating in distro's, as they wouldn't have to grep over the running processes to find the PID of sab.

I submitted a working ebuild script with init and configuration files to the Gentoo bugzilla here. It works nicely for my use case, which is a single SAB instance. I don't use any sed/awk trickery when starting or stopping the process via start-stop-daemon, and the sabnzbd-[port#].pid file contains the appropriate PID.

Since I start my SAB instance from a given configuration file (/etc/sabnzbd/sabnzbd.ini), I know my port number at runtime and the naming scheme that shypike chose is valid. I haven't tested it in the case of a changed port via the web interface, however.

But how do you know what file is created?. I'm not too familar with the gentoo bug tracker etc, nor how you've written the stuff. Actually, how does your script understand the pidfile. It actually looks like your using start-stop-daemon, which is creating a pidfile itself and your managing that. It doesn't look like your actually using the pid thats generated from sabnzbd to kill it.

But the current system will make any pidfile, such as sabnzbd-8080.pid. So I either have to use sed/awk trickey on the sabnzbd.ini to find the port to find the correct pid file. This seems overly-complicated, and requires more info than any init/rc.d script should need to know.

I've yet to see a proper init script for sabnzbd, that isn't relying on the fact that there is only one version running at a time. I wanted to write an init script to be independent, so a user could start a seperate instance if they please, and have the init script only control the correct daemon instance. I'm thinking maybe I should fork sabnzbd master on git and change it to accept pidfiles, rather than folders.

Correct. When I wrote that script, I used start-stop-daemon (the standard process manager for services in Gentoo, probably other Linuxes as well). I start SABnzbd with the --pid argument, which creates the appropriate file in /var/run/sabnzbd/ so I don't have to know the PID directly.

I believe that if SABnzbd.py could be launched with a --port argument, you could create a clean init script that could launch multiple instances without issue. It looks like --server can accept a host:port argument, so that might get you what you want.

I would have preferred a pidfile argument instead of a directory as well, but it worked sufficiently for my single-server case.

Yeah It's definitely possible to make things that work in the single-server case .

The only problem I see with it, is that it requires the init scripts to know information about the server. I know I could pass in the port to sab, but it seems odd to do this as wouldn't it overwrite what is written in sabnzbd.ini. I'd rather have sabs port configured by sabnzbd.ini, rather than an init script.

I know there are plenty of ways around it, I'm sort-of hoping the developers will actually read this and then implement the --pid or --pidfile argument properly in future releases .

If this is still relevant to you:
You can start sabnzbd with the --config-file option so it will use a defined config.ini.

Running multiple instances is easy that way, with two init-scripts.
daemonopts for instance 1: -d --config-file=/path/config.ini --pid=/var/run/sabnzbd/sabnzbd1.pid
daemonopts for instance 2: -d --config-file=/path2/config.ini --pid=/var/run/sabnzbd/sabnzbd2.pid

If you need help scripting it I can provide examples.

Mar2zz wrote:Running multiple instances is easy that way, with two init-scripts.
daemonopts for instance 1: -d --config-file=/path/config.ini --pid=/var/run/sabnzbd/sabnzbd1.pid
daemonopts for instance 2: -d --config-file=/path2/config.ini --pid=/var/run/sabnzbd/sabnzbd2.pid

Except that this won't do what you expect. Using your example, the pid files would be /var/run/sabnzbd/sabnzbd1.pid/sabnzbd-<port1>.pid and /var/run/sabnzbd/sabnzbd2.pid/sabnzbd-<port2>.pid. That makes it relatively hard to use in an init script, as per Mr Fix It's comments, because it requires knowledge of what port a specific instance runs on. Unless you put the pid (for each instance) in a directory by itself, which happens to be a (probably unintended) side effect of your example, and just assume that whatever the port and thus the pid filename, it must be the correct instance.

It's easy to write a script with pgrep -f /path/to/config.ini. That results in a processid, and if --pid was used in the deamonopts you would also know the pidfile.

oh wait , sabnzbd only uses path as option for pid? not pidfile itself? That needs another approach in an initscript. Now I understand this thread :p
I am used to different --pid behaviour in other pythonprograms (sickbeard, couchpotato,calibre,headphones, all have pid-files specified instead of directorys.)

Well that does leave a featurerequest open... the --pid-file= option

(setting the config.ini in an initscript makes grepping the port a lot easier of course, as you know the location of it, thus you know where to grep a port, but that's a workaround, but also easy to do).

Using pgrep defeats the purpose of a pid file; in fact, that's what I've been using all along. But pid files also have other advantages, like enabling other programs to monitor services.

Mar2zz wrote:Well that does leave a featurerequest open... the --pid-file= option

Yup.

Mar2zz wrote:(setting the config.ini in an initscript makes grepping the port a lot easier of course, as you know the location of it, thus you know where to grep a port, but that's a workaround, but also easy to do).

While the ini location is pretty predictable, just using grep on it won't do. There's too much issues with that, including the fact that there's multiple settings by the name of "port". So trying the figure out the port this way would actually require completely parsing the thing, or making rather optimistic assumptions about the order in which settings are stored within the file.

Yeah, I see, multiple ports in sabnzbd.ini. The order options isn't always the same in that? Still doable, but to much for inside an initscript indeed.