Menu
▾
▴
[privoxy-users] [ ijbswa-Support Requests-3439090 ] kill subprocesses without main proc dying
|
From: SourceForge.net <no...@so...> - 2011-11-18 00:16:22
|
Support Requests item #3439090, was opened at 2011-11-16 15:48 Message generated for change (Comment added) made by fabiankeil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=211118&aid=3439090&group_id=11118 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: other Group: None >Status: Pending Priority: 5 Private: No Submitted By: Mark Blattner (markblattner) >Assigned to: Fabian Keil (fabiankeil) Summary: kill subprocesses without main proc dying Initial Comment: I am using Privoxy 3.0.3 on Slackware 10.0.0. I find that occasionally subprocesses of privoxy (beyond the initial instance and its "dispatcher" process) hang on for long periods after the page they got is long forgotten. I would like to deal with this by having a script run periodically (outside privoxy) and kill privoxy subprocesses that fit reasonable criteria for being ..defunct?.. However, I find that killling any subprocess causes all privoxy processes to die. Is this intended behavior? How might I deal with this? SF login markblattner ---------------------------------------------------------------------- >Comment By: Fabian Keil (fabiankeil) Date: 2011-11-17 16:16 Message: Does "subprocesses" mean threads? All POSIX threads belong to the same process so they can't be killed individually by sending a signal. It should be possible to terminate them through the debugger, though. If you really build a Privoxy version that uses forks instead of threads, killing individual processes should be possible (at least it works with 3.0.18 which will be released this weekend), but letting Privoxy fork to handle connections is not recommended and poorly tested. Given that Privoxy 3.0.3 has been released in 2004, I'd suggest you update to a later version to see if the problem still exists. Later versions also have various timeout options that can prevent hanging in certain situations. Without a log file it's hard to tell what's going on and if setting a timeout could help, though. If the problem really still exists, I think it should simply be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=211118&aid=3439090&group_id=11118 |