On 24/06/2008, at 9:27 AM, Christoph Willing wrote:
On 23/06/2008, at 11:58 AM, Jason Bell wrote:
Colleagues
This is just a quick email to warm about issues in regards to updating
to the latest kernels in Fedora.
It has been found that using kernels 2.6.25.6-27.fc8 and 2.6.25.4-10.fc8
(Fedora 8) has caused issues in regards to "multiple instances of vic
(producer and service) "locking up". Basically, only one of the streams
will transmit, whilst the others will lock up.
This isn't just a Fedora thing, I just had the same problem with another distro upgraded to 2.6.25.8 (although no vic lock ups in this case). Rather, its a kernel version (2.6.25) issue - in particular its interaction with python.
chris
For those in a hurry, here's short fix until something more elegant is devised:
1. edit your ~/.AccessGrid/local_services/VideoService/ VideoService.py (or VideoProducerService/VideoProducerService.py) to include a new import:
from random import getrandbits
2. then search for "os.getpid()" and replace it with "getrandbits(16)"
3. now restart your VenueClient
For those interested in the background to the problem, each time VideoService.py is run (i.e. for each video device) an individual temporary startup file is created containing various startup parameters including the video device name (/dev/video0 etc.). Each of these startup files should have a unique name, normally constructed using the process id of the current (VideoService.py) process using python's os.getpid() function. Previously this returned a new pid for each service, but for some reason it now (with kernel 2.6.25) returns the process id of the VenueClient itself. This means that each of the startup files now has the same name (in fact each new one overwites the previous one) resulting in all vics being started with the same startup file. Each vic then tries to open the single video device named in that startup file. Only the first vic to run succeeds in grabbing the video device, the others trying to grab it just cause problems.
Replacing os.getpid() with getrandbits() ensures that each of the vic startup files has a unique name so that all vics can run as configured.
chris
An interesting side effect is that you cannot manually "kill" the locked
up "vic" process. Though xkill seems to work.
Additionally, if you add each stream manually (using configure node
service), rather than loading from a configuration, this appears to work
fine.
Will keep you posted when through testing has been conducted and any possible resolutions found.
Therefore, for now, I recommend not updating your kernel and/or nvidia /
xorg drivers.
We are also investigating whether there are any issues with out "Linux"
variants, but it appears that most other Linux distributions still only
run 2.6.24.xxx kernel, rather than 2.6.25.xxx, which appears to be the
problematic version.
Thanks for your time, Jason.
-------------------------------------------- Jason Bell, B.I.T. (Honours)
Research Systems Support Officer Information Technology Division Central Queensland University
Australian Research Collaboration Service http://www.arcs.org.au/
E-mail : j.bell@xxxxxxxxxx jason.bell@xxxxxxxxxxx Work : +61 7 4930 9229 Mobile : 0409 630897 Postal : Building 19 Central Queensland University Bruce Highway Rockhampton, Queensland, Australia, 4702 -------------------------------------------- Patience is a virtue.
But if I wanted Patience, I would have become a Doctor. --------------------------------------------
_______________________________________________ accessgrid-l mailing list accessgrid-l@xxxxxxxxxxxxxxxxxxx http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l
Christoph Willing +617 3365 8350 QCIF Access Grid Manager University of Queensland
_______________________________________________ accessgrid-l mailing list accessgrid-l@xxxxxxxxxxxxxxxxxxx http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l
Christoph Willing +617 3365 8350 QCIF Access Grid Manager University of Queensland