That's fine. I'll just kill it manually by kill -9. There's no need to fix it then. Thanks for looking into this. My troubles right now is more with the latest update with chrome. See ticket #877. I wonder if anyone else has the issue, or is this another ubuntu problem. Regards Jiang
On Fri, Jun 12, 2015 at 9:24 AM, Antoine Martin <[email protected]> wrote: > On 11/06/15 21:50, Jiang Qian wrote: >> Hi everyone, >> I'm puzzled whether this behavior is intended or not, so I ask this >> list rather than file a bug report. When I quite xpra instance on the >> server by doing first >> xpra list >> to find out which display it's running on (e.g. :100) >> and then do >> xpra stop :100 >> the xpra instance stops successfully, as xpra list shows no running instance. >> But if I do this on the server >> ps|grep pulse >> and I found instances of pulse audio stopped by xpra still running. > That would be an Ubuntu bug, I have created a ticket for it: > http://xpra.org/trac/ticket/889 >> When I start a new instance of xpra server, a new instance of pulse >> audio start. If I kill the old pulse audio, the sound on the new xpra >> instance is not affected. > Just be aware that you can only have a single pulseaudio instance per > user unless you start messing with its environment. > That's a pulseaudio "feature". >> This happens both on 0.14 branch and 0.15 branch. I'm running both >> server and client on ubuntu 14.04 > I've just tried this with a brand new user and the pulseaudio process > did get killed when the server was stopped. But that was on Fedora... > > In your server log, you should see messages like these right at the end: > (..) > Shutting down in response to request > stopping pulseaudio with pid 19682 > xpra is terminating. > removing socket /home/xpratest/.xpra/myhostname-20 > killing xvfb with pid 19665 > > You can also see details on the processes started by xpra with: > xpra info | grep "^child" > > And then I tried it on Ubuntu Trusty and found that it restarts a brand > new process after we kill the pulseaudio server. > So, it's a "feature" that sending a SIGINT does not stop it properly, sigh. > > Cheers > Antoine >> >> Jiang >> _______________________________________________ >> shifter-users mailing list >> [email protected] >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > _______________________________________________ > shifter-users mailing list > [email protected] > http://lists.devloop.org.uk/mailman/listinfo/shifter-users _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
