Opened 14 years ago
Closed 12 years ago
Last modified 12 years ago
#9014 closed Bug Report - General (Won't Fix)
closing page with FLV playback sends HUP to other processes
Reported by: | Owned by: | Rob Smith | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Plugin - MythWeb | Version: | Master Head |
Severity: | high | Keywords: | |
Cc: | Ticket locked: | no |
Description
Hi,
I have BE 26493 running on ArchLinux?. All my processes/daemons are started/supervises via runit. When I launch FLV playback in mythweb and pressing back in browser (or close) web page - all processes in my BE which are enabled to HUP are closed (e.g. dhcpd, smartmod, xined, nfsd, etc). It looks like mythweb after detecting closed web page - sends HUP and this is affecting many system processes. I'm not sure is this issue an result of my system miss-configuration, or bug in mythweb.
Steeps to reproduce:
1.Launch FLV playback in mythweb
2.wait till it start play
3.close page in web browser or press BACK on web browser
4.after few seconds there is HUP signal sent to daemons/processes - and some of them are exiting.
Attachments (1)
Change History (22)
comment:1 Changed 14 years ago by
Priority: | major → minor |
---|---|
Severity: | high → medium |
Status: | new → assigned |
comment:2 Changed 14 years ago by
Milestone: | 0.24 → unknown |
---|
comment:3 Changed 14 years ago by
Milestone: | unknown → 0.24 |
---|
comment:4 Changed 14 years ago by
Resolution: | → Fixed |
---|---|
Status: | assigned → closed |
comment:5 Changed 14 years ago by
Kormoc, Thx for keeping eye on this ticket. Unfortunately issue seems to be still present. If You need me for debugging - I'm happy to help. Pls advice how to progress.
comment:6 Changed 14 years ago by
Resolution: | Fixed |
---|---|
Status: | closed → new |
comment:8 Changed 14 years ago by
Status: | assigned → infoneeded |
---|
What's your webserver setup? Apache? Lighthttpd? SELinux? AppArmor?
We try to group the ffmpeg processes and term them all, but that only works if the isolation level we expect exists, so we need to figure out why it doesn't in your case.
comment:9 Changed 14 years ago by
Hi, OS is ArchLinux?. Webserver is Lighttpd 1.4.26. Despite I replace whole init subsystem (my is based on runit) - rest of the system is standard Arch. Many packages are built be me but I don't think it is root cause. Interesting is HUP looks to system wide as all processes enabled to interpret HUP are exiting. I attach my webserver config. What else You need to know ?
comment:11 Changed 14 years ago by
Daemon is launched from root. HTTP docs dir has httpd:httpd but I turned off rights checking for server-side scripts execution, as I'm using some perl based remote maintenance scripts on my web server.
comment:12 Changed 14 years ago by
Can you comment out line #32 of modules/stream/stream_flv.pl
Should be
kill(-1, $ffmpeg_pgid) if ($ffmpeg_pgid);
I believe that the grouping is failing under lighttpd and thus sending the signal to all the root user processes. If so, we'll have to detect lighttpd and bypass that signal, but verification would be nice
comment:13 Changed 14 years ago by
Hi. I can confirm. Comenting line #32 solves problem (but of course now exiting/closing browser lefts zombie ffmpeg proc.).
comment:15 Changed 13 years ago by
Hi. Sorry for late replay. I modified stream_flv.pl shutdown handler in a following way:
sub shutdown_handler {
kill(1, $ffmpeg_pid) if ($ffmpeg_pid); kill(-1, $ffmpeg_pid) if ($ffmpeg_pid);
}
This is good compromise as I don't have original issue, ffmpeg proc is killed when page is exited/closed and I can still use buggy lighttpd. br
comment:16 Changed 13 years ago by
Milestone: | 0.24 → 0.24.1 |
---|
comment:17 Changed 13 years ago by
Status: | infoneeded → assigned |
---|
comment:18 Changed 13 years ago by
Severity: | medium → high |
---|---|
Type: | defect → Bug Report - General |
comment:19 Changed 13 years ago by
Milestone: | 0.24.1 → 0.24.2 |
---|
comment:20 Changed 12 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | assigned → closed |
I'm closing this one as Won't Fix for now. The code in question is slated for replacement with the new transcoding interface available through the Services API.
Please read the ticket howto, don't set the milestone, priority or severity - A developer will set these.