SABnzbd and PID File under Linux

[mason]

heyho guys,

since im deeper and deeper into linux and running sab now for some years, i wonder if sabnzbd is cabable of generating a pid file, if it's allready capable of using a pid file point me in the right direction please otherwise maybe a feature request?

i would love to use a pid file for scripting and monitoring ....

thanks in advance ... mason

[shypike]

I'm not sure that it's a good idea to let SABnzbd create the PID file itself,
since it's possible to run multiple instances of SABnzbd.
Most people use some start/stop script to control SABnzbd startup and shutdown.
So it would make sense to let this script create the PID file.

SABnzbd could be made to return the PID as an exit code when started with --daemon.
Actually, the PID is not that useful, knowing the http address it listens on, would be more useful.

[jcfp]

SABnzbd could be made to return the PID as an exit code when started with --daemon.

+1 for that suggestion. Once the pid is known, everything else can found via some simple scripting.

[shypike]

Is there a standard location across Unix systems where you can store the pidfile?
My Ubuntu box uses /var/run, but I would not be surprised if this varies over systems.

[mantis006]

/var/run/* is a common place for PID files on gentoo as well.

I've seem hamachi do what you're suggesting, creating a state file ( / etc/hamachi/state) that contains information about the running instance (username, identity, etc).  This info could then be easily parsed; however, I don't think /etc is the proper directory to store that type of file in. I can't think of a standard directory for this type of files like you find in /proc that but for things other than the kernel, /var/run would be much more appropriate alternative (not just for pid files from the looks of things).

Using a conf.d script (imported into init.d scripts - startup, shutdown, status, etc scripts for daemons) to handle certain variables like hostname, port, config file, etc is common and you could have your startup script write this data to a consistently formatted "state" file to be parsed later.

I have never seen more than one instance of SABnzbd.py running at once, something like:

Code: Select all

PID=`/bin/ ps -e | /bin/grep "SABnzbd.py" | sed 's/ \([0-9][0-9]*\)[\t ]\(.\)*/\1/'`
# please remove extra space between /bin and ps, i had to put that there or the forum gave me a "cannot post" error

would give you the PID SABnzbd.py runs under.  I'd Ask the devs to be sure though...

There is something very screwy going on with "complex" statements sent to the forum in a post.  I've observed having to place spaces where they normally don't go in order to successfully post.  Try typing binps (replace with /) like in my code block above, it will give an error; however, "/bin/ ps" (with extra space) will not throw an error.  Sent inpheaux a PM as requested.

Hope this helps.

[shypike]

(why am i getting "cannot post to index.php" errors?)  I have more to say on this...

Please send a PM to inpheaux, our forum operator.

[hamfactorial]

My apologies for bumping the old post, but it's unresolved and highly relevant to me.

I'm working on an init script for Gentoo Linux using SABnzbd 0.6.0, and I'd like to have a way to launch SAB and get a PID back.  I notice that you get the pid using os.fork() in SABnzbd.py, but it's not returned or used anywhere outside of that script.

The standard method for starting services on Gentoo is by using start-stop-daemon.  start-stop-daemon lets me, for example, run the SAB process as a specific user (I don't like running net-accessible services as root).  start-stop-daemon, however, exits abnormally when used to launch interpreted python scripts, and reports the status of the service as [crashed], even though it launches correctly.

Currently, I accomplish this task by using "su" instead, which switches to a specific user prior to launching SABnzbd.py with python directly.  I shut down the service with a direct call to the HTTP interface using http://localhost/shutdown?session=[api_key].  I can't guarantee, however, that the process will actually shut down, since I don't know its PID.  I could kill all the python processes with SABnzbd.py in the name, but that could kill a difficult process that I might want to keep running.

If SAB provided a method to return its PID after successfully daemonizing, multiple copies could be started and stopped individually by PID later, using start-stop-daemon.  What are your thoughts?

[shypike]

The only PID return method I can think of is the exit code.
Using the exit code doesn't sound like a solid idea.
Any other ideas?

Besides, you're asking us to compensate for a bug in the start-stop-daemon?

Writing to /var/run is only possible for root and doesn't support multiple instances,
that's why we never implemented it.

[hamfactorial]

shypike:

If you don't want to use an exit code for a PID, that's reasonable.  /var/run is certainly only writable by root, but packages can install their own subdirectories to play in, with appropriate permissions.  For instance, my tomcat webserver has a /var/run/tomcat-6 directory, owned by tomcat:tomcat.  All of its PID files are located there, and freely readable/writable by the tomcat user and group only (plus root).

I've created a /var/run/sabnzbd directory, owned by root:sabnzbd.  Any user in the sabnzbd group can read/write into that directory and create/destroy the PID file as desired.

The PID file could take the form /var/run/sabnzbd/id.pid, where id is some unique runtime code that SAB generates on startup.  My first thought was that the api_key could be the id, so one could identify the PID of a given SAB instance by its api_key.  Only users in the appropriate sabnzbd group could read that, keeping the keys from getting loose.

[shypike]

The api key is not a good choice because it can change during a session.
host_port.pid would be unique enough.
My objection is still that it would be a feature for a very small audience.

[hamfactorial]

You're right, port.pid would be a unique solution, since it wouldn't make any sense to run multiple SAB instances on the same port.

If this request is too obscure, I'll cook up my own solution using some shell scripting instead.  Cheers!

[shypike]

We'll see.
If it's not too complex it might get implemented.
Don't expect to much fanciness, like support in the UI.

[hamfactorial]

We'll see.
If it's not too complex it might get implemented.
Don't expect to much fanciness, like support in the UI.

Thank you for looking into it, shypike.  I prefer the command line anyway, so an obscure switch would be great for me.  No need to bring the GUI into it

[shypike]

You're going to get it in 0.6.1
--pid

[hamfactorial]

You're going to get it in 0.6.1
--pid

Great news, shypike! Thank you. I'll submit the package to gentoo's bugzilla and try to have it included in the official tree.