Hi,
It seems this subject has been discussed earlier: http://sourceforge.net/mailarchive/message.php?msg_id=10508275 Basically the problem is that if something causes jackd's watchdog to trigger, the entire process group is killed. If jackd was started from the window manager it will be started in the same process group as the window manager itself, this is the way it works with KDE atleast, result being that X will be killed. Not good at all. Chris Cannam pointed me to the relevant code: lines 911-912 and 916 http://cvs.sourceforge.net/viewcvs.py/jackit/jack/jackd/engine.c?annotate=1.126 Simplest solution; just remove the kill statements ? Regards, Robert -- http://spamatica.se/musicsite/ ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
On Thu, 2005-07-14 at 23:15 +0200, Robert Jonsson wrote:
> Hi, > > It seems this subject has been discussed earlier: > http://sourceforge.net/mailarchive/message.php?msg_id=10508275 > > Basically the problem is that if something causes jackd's watchdog to trigger, > the entire process group is killed. If jackd was started from the window > manager it will be started in the same process group as the window manager > itself, this is the way it works with KDE atleast, result being that X will > be killed. > Not good at all. > > Chris Cannam pointed me to the relevant code: > lines 911-912 and 916 > http://cvs.sourceforge.net/viewcvs.py/jackit/jack/jackd/engine.c?annotate=1.126 > > Simplest solution; just remove the kill statements ? absolutely not. these jack days calls setsid() to get itself established as a new process group leader. if KDE is taking steps to prevent even that from dissociating jackd from the X session, then KDE is broken and needs fixing. i remember last year reading other programs' bug reports about this, and it looked as if KDE was going to fix it. the only condition under which the kill statements can be replaced/removed is if someone demonstrates an equally effective method of killing all relevant threads/processes. --p ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
> >
> > Simplest solution; just remove the kill statements ? > > absolutely not. > > these jack days calls setsid() to get itself established as a new > process group leader. if KDE is taking steps to prevent even that from > dissociating jackd from the X session, then KDE is broken and needs > fixing. i remember last year reading other programs' bug reports about > this, and it looked as if KDE was going to fix it. I see! I'm just the messenger here, haven't experienced this myself... Indeed, I see now in the code that setsid has been there since 2003. Probably you are correct and there is/was something wrong in KDE. I'll dig a bit. One more thing, I think it was demonstrated that starting jack from inside qjackctl and first doing setsid(8) did help.. not entirely sure what that means.. > > the only condition under which the kill statements can be > replaced/removed is if someone demonstrates an equally effective method > of killing all relevant threads/processes. Ok. Regards, Robert > > --p -- http://spamatica.se/musicsite/ ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
In reply to this post by rj (Bugzilla)
Paul Davis:
> On Thu, 2005-07-14 at 23:15 +0200, Robert Jonsson wrote: > > Simplest solution; just remove the kill statements ? > > absolutely not. No, killing the process group is probably the right thing to do here. But: > these jack days calls setsid() to get itself established as a new > process group leader. jackd does; libjack doesn't (and shouldn't). I believe the watchdog kills the process group of jackd and the process group leader of the current client. Maybe just modifying the watchdog so as to kill the jackd process group but only the single client process would be appropriate. Maybe the necessary data isn't there. I don't have the source in front of me at the moment. Chris ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
In reply to this post by rj (Bugzilla)
... and
> process group leader. if KDE is taking steps to > prevent even that from > dissociating jackd from the X session Is that possible? Chris ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
In reply to this post by rj (Bugzilla)
We had a similar problem where the watchdog would end up killing klauncher.
This was because we had used klauncher to start jackd in the first place. The solution that's worked for us to start jack thusly (from within out jack control panel's init function): if( fork() == 0 ) { execvp(argv[0], argv); _exit(0); } The end result being that jackd is properly dis-associated from klauncher and can cause no more trouble. On Thursday 14 July 2005 02:15 pm, Robert Jonsson wrote: > Hi, > > It seems this subject has been discussed earlier: > http://sourceforge.net/mailarchive/message.php?msg_id=10508275 > > Basically the problem is that if something causes jackd's watchdog to > trigger, the entire process group is killed. If jackd was started from the > window manager it will be started in the same process group as the window > manager itself, this is the way it works with KDE atleast, result being > that X will be killed. > Not good at all. > > Chris Cannam pointed me to the relevant code: > lines 911-912 and 916 > http://cvs.sourceforge.net/viewcvs.py/jackit/jack/jackd/engine.c?annotate=1 >.126 > > Simplest solution; just remove the kill statements ? > > Regards, > Robert -- Sean Meiners [hidden email] Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse; ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
On Thu, 2005-07-14 at 18:14 -0700, Sean Meiners wrote:
> We had a similar problem where the watchdog would end up killing klauncher. > This was because we had used klauncher to start jackd in the first place. > The solution that's worked for us to start jack thusly (from within out jack > control panel's init function): > > if( fork() == 0 ) > { > execvp(argv[0], argv); > _exit(0); > } > > The end result being that jackd is properly dis-associated from klauncher and > can cause no more trouble. i believe this is caused by using an older version of JACK that did not have the setsid() call in place. that in turn is caused by the fact that it took us so long to get the most recent release out there. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
Sorry, I should have specified, we're currently using 0.100.0 and this fix was
still needed. I should also note that I'm starting jackd with the suid jackstart wrapper to gain realtime capabilities. On Thursday 14 July 2005 06:44 pm, Paul Davis wrote: > On Thu, 2005-07-14 at 18:14 -0700, Sean Meiners wrote: > > We had a similar problem where the watchdog would end up killing > > klauncher. This was because we had used klauncher to start jackd in the > > first place. The solution that's worked for us to start jack thusly (from > > within out jack control panel's init function): > > > > if( fork() == 0 ) > > { > > execvp(argv[0], argv); > > _exit(0); > > } > > > > The end result being that jackd is properly dis-associated from klauncher > > and can cause no more trouble. > > i believe this is caused by using an older version of JACK that did not > have the setsid() call in place. that in turn is caused by the fact that > it took us so long to get the most recent release out there. -- Sean Meiners [hidden email] Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse; ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
In reply to this post by Chris Cannam-2
"Chris Cannam" <[hidden email]> writes:
> I believe the watchdog kills the process group of jackd and the > process group leader of the current client. Until fairly recently that was the case. It was causing problems. > Maybe just modifying the watchdog so as to kill the jackd process > group but only the single client process would be appropriate. Maybe > the necessary data isn't there. I don't have the source in front of > me at the moment. I already made this change. It's in the current release. -- joq ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
On Friday 15 Jul 2005 20:23, Jack O'Quin wrote:
> "Chris Cannam" <[hidden email]> writes: > > I believe the watchdog kills the process group of jackd and the > > process group leader of the current client. > > Until fairly recently that was the case. No, until fairly recently it killed the process group of jackd and the process group of the current client. You changed it to the behaviour I just described. Chris ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
Chris Cannam <[hidden email]> writes:
> On Friday 15 Jul 2005 20:23, Jack O'Quin wrote: >> "Chris Cannam" <[hidden email]> writes: >> > I believe the watchdog kills the process group of jackd and the >> > process group leader of the current client. >> >> Until fairly recently that was the case. > > No, until fairly recently it killed the process group of jackd and the > process group of the current client. You changed it to the behaviour I > just described. D'oh! Looks like I screwed up. I had intended to do what you suggested, but ended up doing as you described by mistake. :-/ -- joq ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
> Chris Cannam <[hidden email]> writes: >> No, until fairly recently it killed the process group of jackd and the >> process group of the current client. You changed it to the behaviour I >> just described. "Jack O'Quin" <[hidden email]> writes: > I had intended to do what you suggested, but ended up doing as you > described by mistake. :-/ This patch should kill the right process. Maybe some of you can see if it fixes the problem Robert reported. It's difficult to generate watchdog timeouts intentionally. Index: jackd/engine.c =================================================================== RCS file: /cvsroot/jackit/jack/jackd/engine.c,v retrieving revision 1.125 diff -u -r1.125 engine.c --- jackd/engine.c 11 May 2005 02:06:46 -0000 1.125 +++ jackd/engine.c 15 Jul 2005 22:27:58 -0000 @@ -909,7 +909,7 @@ /* Kill the current client (guilt by association). */ if (engine->current_client) { kill (engine->current_client-> - control->pgrp, SIGKILL); + control->pid, SIGKILL); } /* kill our process group, try to get a dump */ -- joq ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Jackit-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jackit-devel |
Free forum by Nabble | Edit this page |