GNOME Bugzilla – Bug 626968
the speed-dispatcher process is not killed by the orca shellscript
Last modified: 2010-08-15 23:47:15 UTC
The is a function cleanup() in /usr/bin/orca that kills all the process Orca launch. The list of the process (actually their regular expression) is in the code but is not updated and it has not the speech-dispatcher. This means the cleanup() function won't kill the process speech-dispatcher if we don't add it to the list.
Created attachment 167899 [details] [review] Patch for adding the speech-dispatcher This should fix the bug. There is also some shellscripting clean up done.
hmm, I am not sure about killing sd some people use speakup or sbl from the consol, and they might be running sd service as a user, and therefore i dont think we should kill sd on their behalf. Afterall we didnt start it in the first place, someone else did, and if it was unavailable the python bindings would tell us that a connection to the sd server was unsuccessful. (probably we shouldnt be killing festival server either, because sd might be using festival to produce speech) Thanks.
Jon there happens to already be a downstream Ubuntu patch which kills speech-dispatcher. If doing so was a problem, would we not have heard something by now from the users, since most Orca users are Ubuntu users?
I am not aware of the patch you mension or its purpose, but since we didnt start sd, i dont see the reason for killing it. I can imagine the patch is when sd segfaults, that it kicks it alive again, but there has been a lot of cleaning up recently on the sd code, so it should be happening less and less. The intension of the previous comment was simply a cautionary note. Thanks.
(In reply to comment #2) > hmm, I am not sure about killing sd > some people use speakup or sbl from the consol, and they might be running sd > service as a user, and therefore i dont think we should kill sd on their > behalf. > Afterall we didnt start it in the first place, someone else did, and if it was > unavailable the python bindings would tell us that a connection to the sd > server was unsuccessful. (probably we shouldnt be killing festival server > either, because sd might be using festival to produce speech) Well, the comment above the code says we should kill any gnome-speech synthesis drivers, and festival processes running in server mode. That's why I did it. But also because I saw the Ubuntu patch about killing the sd. I'm not sure yet where, but Orca does start the sd. If I kill all sd instances and I launch Orca, there will be a new sd running, so Orca must launch it at some point. Probably is better idea to get the pids from the Python code and take care of those specific process created by Orca, from the Python code itself. I'm not happy with having a shellscript launching and controlling the actual Orca's Python code anyway... I don't see too much difficult to move the script functionality to the Python code and we'll have more control, I think.
(In reply to comment #5) > Well, the comment above the code says we should kill any gnome-speech synthesis > drivers, and festival processes running in server mode. That's why I did it. yes, probably that code was written when the speech solutions had lock on the sound device, and therefore freeing them was important so that other applications could produce sound. > But also because I saw the Ubuntu patch about killing the sd. > > I'm not sure yet where, but Orca does start the sd. If I kill all sd instances > and I launch Orca, there will be a new sd running, so Orca must launch it at > some point. yes, i see this behaviour too, but without looking at the code, i cant say where it is happening. > I'm not happy with having a shellscript launching and controlling the actual > Orca's Python code anyway... I don't see too much difficult to move the script > functionality to the Python code and we'll have more control, I think. I agree with you on this one. Thanks.
(In reply to comment #4) > I am not aware of the patch you mension or its purpose, but since we didnt > start sd, i dont see the reason for killing it. Well, as has since been commented, we are causing the process to be spawned. So I would think a reason for killing it is that we should clean up after ourselves. > I can imagine the patch is when sd segfaults, that it kicks it alive again, Not sure about that. But that downstream patch does a 'kill' if it finds an instance of speech-dispatcher running. The other thing going through my head is this: As you know, the a11y guy for Canonical is Luke. As you also know, Luke is a speech-dispatcher developer. If killing speech-dispatcher was a bad idea -- or one which is now unnecessary -- my guess is that the downstream patch in question would not exist. Then again, maybe not. <shrugs>
(In reply to comment #7) sounds fine then, until we move to a diffrent way of cleaning up after ourselves.
(In reply to comment #5) Given that Jon doesn't have additional objections.... > Probably is better idea to get the pids from the Python code and take care of > those specific process created by Orca, from the Python code itself. This sounds cleaner to me. If you could create a new patch which does that, it would be awesome. Thanks Juanje!
hi all, ok, here's what's up with the spawning, if the python sd api can't connect to a speech dispatcher server it will start one. I don't know why ubuntu has that patch, but I'm pretty sure its broken, and would want to ping Luke about it. The basica problem with the idea of killing the sd daemon is this, orca may or may not have started one, it may be running on a different machine, or as a different user, and other clients may be using it. Heres own path this will go wrong killall orca start orca # assume sd is spawned we can't find one so create it. start another program that connects to sd # speechd-up / sbl / yasr / other thing, I believe there is atleast one gameish or chatish thing out there that uses it. exit orca # you kill sd now that other app has lost its connection As for why no one has complained I would gues that very few people exit orca normally, rather it gets killed either by a user or something else, I'm thinking about lockups and such. The reason for the sd spawning as I understand it is to provide the same ability as gnome-speech for auto starting, the difference is that orca may not be the only user. At any rate that's why I think this is wontfix, but it may be worth pinging Luke. thanks! Trev
Thanks Trev. But as Juanje suggested in comment #5: > Probably is better idea to get the pids from the Python code and take care of > those specific process created by Orca, from the Python code itself. If we have the PID of speech-dispatcher spawned from a specific instance of Orca, wouldn't it be safe (and desirable) to kill that one particular process? Or am I (still) missing something?
Hi, no that's not actually safe, look at the path I showed before, you have no knowledge of who else is using the sd server you caused to be created. You know you were the first client that wanted it, but there is nothing to prevent other clients from connecting after you have. depending on what speech dispatcher version you are using either a unix socket ~/.speech-dispatcher/speechd.sock or localhost 6560 will be listened on by speech dispatcher, any body can connect to this socket, and could be connected when you exit from orca, and killing speech dispatcher will mean they lose there connection. Its pretty easy to see this with tcp, if you're using sd 0.6.7 this is the default, otherwise you can start a sd listening on a tcp port like this speech-dispatcher -P /tmp/foo.pid -C /etc/speech-dispatcher -p 5555 -c inet_socket now connect with telnet telnet localhost 5555 then speak a message type SPEAK enter then some message say "this is a very silly client" then enter then type a dot then enter again you should here the message. now kill speech-dispatcher with killall speech-dispatcher then go back to the telnet session you'll see it died with remote host closed the connection, if that was a real client it would be rather unhappy :-) HTH Trev
Thanks Trev. Your comments, and our subsequent chat, do indeed help. Juanje, in light of Trev's comments, if you agree that this is something that we should indeed not pursue then please close this but out as WONTFIX. (For now, I'll leave it open in case you have additional thoughts/information relevant to the situation.)
The patch in Ubuntu is Ubuntu-specific, and was a hack to make sure things behaved correctly when using gdm/a user session and Orca speaking. I need to clean it up/remove it for maverick, after I re-assess where things stand with SD 0.7 and expected behavior.
(In reply to comment #13) > Juanje, in light of Trev's comments, if you agree that this is something that > we should indeed not pursue then please close this but out as WONTFIX. (For > now, I'll leave it open in case you have additional thoughts/information > relevant to the situation.) I'll change it to WONTFIX but now I have one doubt, sould we remove also the GNOME_Speech and festival from that list? I see the Trev's points GNOME_Speech so maybe we shouldn't kill either the other subprocesses (gnome-speech synthesis drivers and festival process).
I had asked Trev that earlier today via IRC. ~~~~~~~~~ 02:20:02 AM) joanie: so tbsaunde we're currently killing other things, like gnome-speech and festival (02:20:12 AM) joanie: should we not be doing that either? (02:23:25 AM) tbsaunde: joanie: I now /zero/ about gnome-speech if other people can connect to the process you started then you shouldn't if you are the only possible client then its fine (02:24:13 AM) joanie: And I don't know the answer to that question. Would have to research it. Given that gnome-speech is deprecated, I guess that's not a high priority (02:24:17 AM) tbsaunde: joanie: festival is the same if somebody else could be using it you can't I don't know how festival works or how you start it well enough to say ~~~~~~~~~ Let's leave it. We've got far more important things to worry about in terms of bugs, impending freezes (including the UI freeze which is tomorrow), etc. Thanks.