FS#30441 - [deluge] Please patch rc.d initscripts to kill rogue processes properly. PATCH ATTACHED

Attached to Project: Arch Linux
Opened by David Schenck (zero2cx) - Tuesday, 26 June 2012, 01:20 GMT
Last edited by Jan Alexander Steffens (heftig) - Tuesday, 26 June 2012, 10:45 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
The /etc/rc.d/deluge* initscripts do not gracefully account for a user who might muck things up by running /usr/bin/deluged or /usr/bin/deluge-web as a standard or root user. Currently, the initscripts can miss rogue processes, and/or leave orphaned pid files.

The attached patch is an elegant solution to this potential problem. All rogue processes are caught and the pid files are maintained cleanly.

Additional info:
+ Package: deluge 1.3.5-1
+ Bad behavior: /etc/rc.d/deluged
+ Bad behavior: /etc/rc.d/deluge-web

Steps to reproduce:
1) Install deluge package.
2) Launch one or more deluged/deluge-web processes as a standard or root user.
3) Execute 'sudo rc.d start deluge*'.
4) Crap, look at the uncaught processes.
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Tuesday, 26 June 2012, 10:45 GMT
Reason for closing:  Not a bug
Comment by David Schenck (zero2cx) - Tuesday, 26 June 2012, 07:48 GMT Comment by Jan Alexander Steffens (heftig) - Tuesday, 26 June 2012, 08:24 GMT
The rc script's purpose is not to manage every single deluged process on the system, but only one instance, owned by the 'deluge' user. If there are other deluge daemons running, the script should not touch them. This killing spree is definitely the wrong thing to do.

Making sure the pidfile is removed can be useful, though, so I'll add that to trunk.
Comment by David Schenck (zero2cx) - Tuesday, 26 June 2012, 09:15 GMT
Cool. Thanks for the explanation.

If you would, also please explain why would the script(s) try to kill a process twice in the case of rc.d stop ___? That faulty construct and my assumption on why it exists is what sent me down the wrong track. I haven't found any other Arch Linux initscripts constructed this way, and if process exclusivity wasn't what was intended... What was intended here?

Thank you. Corrected patch to follow, if you see my point.

Also, would it be helpful to specify a non-default listening port in /etc/conf.d/deluged? That would maybe prevent operational conflict with other running user processes. I don't plan on running more than the one deluged process at a time, but apparently some other user may wish to run it that way. I think that all concurrent processes listen on the same port as installed until the settings are tweaked by the admin.
Comment by Jan Alexander Steffens (heftig) - Tuesday, 26 June 2012, 10:45 GMT
kill -0 just tests if the target process can be signaled (i.e. it must exist). It does not kill.

IIRC deluged picks a random free port by default, so that's a non-issue.

Loading...