[AG-TECH] Problems with Access Grid 3.0.2

Nico nmolina at cesga.es
Wed Oct 24 05:25:49 CDT 2007


Hi!

I'm Nico again, the last problems I told you are solved. I just reboot 
the machine. I'll try to continue to work where we were.

Thank you!

           Nico.

Nico escribió:
> Hi Chris!
>
> First of all, thank you very much for all your help you give me with 
> detailed explanations.
>
> But now, I'm having serious problems and new errors because I can't 
> start manually VenueServer24 either VenueServer3.
>
> When I write VenueServer24 -c VenueServer.cfg -p 8000 I obtain the 
> following error message:
>
> [ag at agserver ~]$ Toolkit Initialization failed, exiting.
> Initialization Error:  [Errno 30] Read-only file system: 
> '/home/ag/.AccessGrid/Logs/VenueServer.log'
> Traceback (most recent call last):
>  File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit
>    self.stream.write(fs % msg)
> ValueError: I/O operation on closed file
> Traceback (most recent call last):
>  File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit
>    self.stream.write(fs % msg)
> ValueError: I/O operation on closed file
> Traceback (most recent call last):
>  File "/usr/lib/python2.4/logging/__init__.py", line 712, in emit
>    self.stream.write(fs % msg)
> ValueError: I/O operation on closed file
>
> Then, I went to read VenueServer.log and these are the last lines (no 
> entry from the last minutes):
>
> GSITCPSocketException: an end-of-file was reached
> 10/24/07 04:04:11 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191451.28.
> 10/24/07 04:04:23 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191463.28.
> 10/24/07 04:04:35 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191475.28.
> 10/24/07 04:04:47 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191487.28.
> 10/24/07 04:04:59 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191499.29.
> 10/24/07 04:05:11 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191511.29.
> 10/24/07 04:05:23 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191523.29.
> 10/24/07 04:05:35 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191535.29.
> 10/24/07 04:05:47 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191547.29.
> 10/24/07 04:05:59 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191559.29.
> 10/24/07 04:06:11 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191571.29.
> 10/24/07 04:06:23 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191583.29.
> 10/24/07 04:06:35 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191595.29.
> 10/24/07 04:06:47 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191607.29.
> 10/24/07 04:06:59 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191619.29.
> 10/24/07 04:07:11 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191631.29.
> 10/24/07 04:07:23 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191643.29.
> 10/24/07 04:07:35 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191655.29.
> 10/24/07 04:07:47 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191667.34.
> 10/24/07 04:07:59 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191679.35.
> 10/24/07 04:08:11 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191691.36.
> 10/24/07 04:08:23 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191703.38.
> 10/24/07 04:08:35 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191715.37.
> 10/24/07 04:08:47 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191727.38.
> 10/24/07 04:10:35 -1275184208 VenueServer     Venue.py:731 DEBUG Got 
> Client Heartbeat for 00000115b87383e400c100900024008c084 at 
> 1193191835.74.
> 10/24/07 04:10:35 -1325806672 Hosting     Server.py:65 ERROR Exception 
> in SOAP server main loop
> Traceback (most recent call last):
>  File 
> "/usr/lib/python2.4/site-packages/AccessGrid2/AccessGrid/hosting/SOAPpy/Server.py", 
> line 63, in Run
>    self._server.handle_request()
>  File "/usr/lib/python2.4/SocketServer.py", line 217, in handle_request
>    request, client_address = self.get_request()
>  File "/usr/lib/python2.4/site-packages/SOAPpy/GSIServer.py", line 
> 140, in get_request
>
>
>
> VenueManagement24 doesn't work too. Error message at starting 
> VenueServer for AG3:
>
> [1] 3666
> [ag at agserver venue_server3]$ Toolkit Initialization failed, exiting.
> Initialization Error:  [Errno 30] Read-only file system: 
> '/home/ag/.AccessGrid3/Logs/VenueServer.log'
>
> I can't understand these new problems! Unbelievable.
>
> Thank you!
>
>                              Nico.
>
>
>
>
> Christoph Willing escribió:
>>
>> On 23/10/2007, at 1:37 AM, Nico wrote:
>>
>>> Hi Chris again!
>>>
>>> Well, I don't where to start but I'll try to explain all my problems 
>>> as well as I can because I have some difficulties with English.
>>>
>>> I didn't try all the solutions you gave me in the last email, but I 
>>> tried the last solution changing the address in 
>>> "persistenceFilename" entry as this:
>>>
>>> persistenceFilename = /home/ag/venue_server3/VenueServer.dat  (The 
>>> same for the Data folder)
>>>
>>> Then, I rebooted the machine and it didn't work, in fact I think I 
>>> obtained some errors, but I'm not sure. So I correct VenueServer.cfg 
>>> again.
>>
>>
>> Nico,
>>
>> I've now tried this method myself and found that it does not work 
>> correctly yet. The server will use the different data store and 
>> persistenceFilename if they are specified in the cfg file, however 
>> the data written to the .dat file is incorrect - a bug for fixing 
>> sometime.
>>
>>
>>
>>> After that I started to have problems with Access Grid 2.4 too (I 
>>> have another script on the startup for VenueServer24). At any way, 
>>> is not the first problem I have with AG2.4. The problem I have is 
>>> that VenueServer.dat (for AG2.4) become corrupt file and 
>>> VenueServer24 runs but with problems, when I execute it I have this 
>>> messages:
>> [snip]
>>>  File "/usr/lib/python2.4/ConfigParser.py", line 520, in get
>>>    raise NoOptionError(option, section)
>>> ConfigParser.NoOptionError: No option 'cleanuptime' in section: 
>>> 'c190248c0648459db8c5401e80b4f0a0'
>>
>> This means that the VenueServer.dat file being used now by your AG2 
>> server was sometime also used by the AG3 server, at which time a new 
>> venue was created. The new venue did not include a 'cleanuptime' 
>> feature (because it is not used by AG3) but it is expected to to be 
>> there by the AG2 server which then complains when the feature is not 
>> found.
>>
>>
>>> Traceback (most recent call last):
>>>  File "/usr/lib/python2.4/logging/handlers.py", line 62, in emit
>>>    if self.shouldRollover(record):
>>>  File "/usr/lib/python2.4/logging/handlers.py", line 132, in 
>>> shouldRollover
>>>    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
>>> ValueError: I/O operation on closed file
>>>
>>> Therefore the quick solution is deleting Data folder and 
>>> VenueServer.dat, then I run VenueServer24 and I go to 
>>> VenueManagement24 to create a default Venue with multicast addresses 
>>> for video and audio. I press Ok to save the configuration and close 
>>> the program. Then to check the configuration I connect a client to 
>>> the server and I see all I configured is ok, however I make a cat to 
>>> VenueServer.dat and the information about the default Venue doesn't 
>>> appear, the file didn't change so it's quite uncomprenhensible. I 
>>> was trying to get some aditional information from Logs and all I 
>>> could find was this clue:
>>
>> The changing configuration is kept in memory and occasionally written 
>> out to the VenueServer.dat file. If the server is shut down before 
>> the new configuration is written out then the VenueServer.dat file 
>> may not contain the correct configuration.
>>
>> You can force writing of the configuration from the VenueManagement 
>> tool from the Server->Checkpoint menu. Wait until this has completed 
>> and then it is safe to close down the server. Hopefully your 
>> VenueServer.dat file will then be correct.
>>
>>
>>
>>> For now I removed the VenueServer script from the startup. First, it 
>>> must work fine manually, then I'll try to find a solution for the 
>>> startup of the services.
>>
>> I think the manual starting will always work because you cd into the 
>> correct directory before you start the server. This cd into the 
>> correct directory must also be part of any startup script you use.
>>
>>
>> chris
>>
>>
>>
>>> Christoph Willing escribió:
>>>>
>>>> On 18/10/2007, at 5:24 PM, Nico wrote:
>>>>
>>>>> Hi Chris!
>>>>>
>>>>> When I start VenueServer manually I use the same command as in the 
>>>>> script file. The syntax is the same. I have a little script 
>>>>> (called venue_server) in /home/ag/venue_server3 with this line:
>>>>>
>>>>> VenueServer -c VenueServer.cfg -p 9000 &
>>>>>
>>>>> So, I just execute at this way: ./venue_server  with  "ag" user.
>>>>>
>>>>> The entry for 'persistenceFilename' in VenueServer.cfg is 
>>>>> 'VenueServer.dat'
>>>>>
>>>>> persistenceFilename = VenueServer.dat
>>>>
>>>> Nico,
>>>>
>>>> From this information, I'm pretty sure your problems are related to 
>>>> the VenueServer being run from the incorrect directory.
>>>>
>>>> When the server is started manually from the venue_server3 
>>>> directory, it runs correctly. That directory contains the correct 
>>>> VenueServer.dat file (and also a Data directory). The 
>>>> persistenceFilename set in the VenueServer.cfg file says 
>>>> 'VenueServer.dat' but note that this is a relative (not absolute) 
>>>> path name. The problem is that it is relative to the location the 
>>>> server is running from, _not_ relative to the location of the 
>>>> VenueServer.cfg file. If the server is run, for instance, from 
>>>> /var/tmp then a VenueServer.dat is expected to be in /var/tmp even 
>>>> when you specify the correct VenueServer.cfg file somewhere else. 
>>>> If no VenueServer.dat file is found, a new one is created 
>>>> containing just a default lobby. If the server is run from 
>>>> /home/ag/venueserver3 directory then the correct VenueServer.dat 
>>>> file is found.
>>>>
>>>> When you run from the init.d script, you're using a 'daemonAG' 
>>>> command which I presume is based on the plain 'daemon' command 
>>>> which is sourced from /etc/rc.d/init.d/functions. If you look at 
>>>> the definition of the 'daemon' function in that file, you'll see 
>>>> that it is just a wrapper for the 'runuser' command (which itself 
>>>> is a cut down version of the more traditional 'su' command). You'll 
>>>> also see that runuser is invoked with the '-' option i.e. it runs 
>>>> in a login shell of the specified user ('ag' in this case). That 
>>>> means that when the VenueServer command is run, it is run from ag's 
>>>> home directory /home/ag, not /home/ag/venue_server3 as you intend.
>>>>
>>>> My guess is that you see your previous venues because you used to 
>>>> run your AG2 venue server the same way and so /home/ag already 
>>>> contains a useable VenueServer.dat file (even if its not the one 
>>>> you intend, which is in the venue_server3 directory).
>>>>
>>>> Was the AG2 server running at the same time you ran the AG3 server 
>>>> from the init.d script? I think this would be a big problem with 
>>>> both the AG2 and AG3 servers attempting to use the same .dat file 
>>>> simultaneously!
>>>>
>>>> The solution is to have your script cd to the correct directory 
>>>> before running VenueServer && preventing it from running from a 
>>>> login shell. If your daemonAG is largely a copy of the 'daemon' 
>>>> function in /etc/rc.d/init.d/functions, then you could edit 
>>>> daemonAG command to remove the '-' option from the invocation of 
>>>> 'runuser' i.e. change the line:
>>>>     $nice runuser -s /bin/bash - $user -c "$corelimit >/dev/null 
>>>> 2>&1 ; $*"
>>>> to:
>>>>     $nice runuser -s /bin/bash $user -c "$corelimit >/dev/null 2>&1 
>>>> ; $*"
>>>>
>>>> Then change your init.d script line:
>>>>     daemonAG --user ag VenueServer -c 
>>>> /home/ag/venue_server3/VenueServer.cfg -p 9000
>>>> to:
>>>>   cd /home/ag/venue_server3 && daemonAG --user ag VenueServer -c 
>>>> /home/ag/venue_server3/VenueServer.cfg -p 9000
>>>>
>>>> If you use this line, you don't really need to specify the 
>>>> VenueServer.cfg location since the VenueServer will look for the 
>>>> cfg file in the directory in which it is running i.e. the line 
>>>> could be:
>>>>   cd /home/ag/venue_server3 && daemonAG --user ag VenueServer -p 9000
>>>>
>>>>
>>>> Another possible solution (untried) is to specify an absolute path 
>>>> name for the persistenceFilename entry in the VenueServer.cfg file 
>>>> i.e. instead of
>>>>     persistenceFilename = VenueServer.dat
>>>> try:
>>>>     persistenceFilename = /home/ag/venue_server3/VenueServer.dat
>>>>
>>>> BTW this problem will also occur with the server's data store which 
>>>> is under the 'Data' directory. This is also specified in the 
>>>> VenueServer.cfg file as the 'dataStorageLocation = Data' entry.
>>>>
>>>>
>>>> chris
>>>>
>>>>
>>>>
>>>>> Christoph Willing escribió:
>>>>>>
>>>>>> On 18/10/2007, at 12:33 AM, Nico wrote:
>>>>>>
>>>>>>> Hi Chris!
>>>>>>>
>>>>>>> Thanks for answering! When I start from the script in init.d and 
>>>>>>> I connect a client and I can see all Venues, but I can't enter 
>>>>>>> in any of them because I obtain the error messages I mentioned 
>>>>>>> in the first mail.
>>>>>>>
>>>>>>> In the script I have a line different than you to execute 
>>>>>>> VenueServer, but I've specified the "ag" user:
>>>>>>>
>>>>>>> daemonAG --user ag VenueServer -c 
>>>>>>> /home/ag/venue_server3/VenueServer.cfg -p 9000
>>>>>>
>>>>>> Nico,
>>>>>>
>>>>>> When you start the server manually and clients can connect to all 
>>>>>> venues, which directory are you starting from? With the line 
>>>>>> above there may be a problem with which VenueServer.dat file is 
>>>>>> used. What is the entry for 'persistenceFilename' in your 
>>>>>> /home/ag/venue_server3/VenueServer.cfg file?
>>>>>>
>>>>>>
>>>>>> chris
>>>>>>
>>>>>>
>>>>>>> Maybe our scripts are different. I used the syntax from this 
>>>>>>> forum:  
>>>>>>> http://www-unix.mcs.anl.gov/web-mail-archive/lists/ag-tech/2006/02/msg00023.html 
>>>>>>>
>>>>>>>
>>>>>>> VenueServer for version 2.4 runs ok with the same syntax.
>>>>>>>
>>>>>>> Thanks again for your help! See you soon!
>>>>>>>
>>>>>>>                      Nico.
>>>>>>>
>>>>>>> Christoph Willing escribió:
>>>>>>>>
>>>>>>>> On 17/10/2007, at 9:53 PM, Nico wrote:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> In our company we have an AG Server on a Linux Fedora Core 4 
>>>>>>>>> machine with Access Grid 3.0.2 installed. We have several 
>>>>>>>>> Venues configured. During these days I've been configuring 
>>>>>>>>> start scripts on the /etc/init.d folder to automatically run 
>>>>>>>>> Venue Server at the start of the system. So the proccess 
>>>>>>>>> VenueServer is ok when I reboot the machine, but when I 
>>>>>>>>> connect a client I can connect to 
>>>>>>>>> https://server:9000/Venues/default but I can't enter in any 
>>>>>>>>> configured Venue on the server, I try it, but I receive the 
>>>>>>>>> following error message: "Error entering venue".
>>>>>>>>>
>>>>>>>>> So the quick solution is start Venue Server again manually, 
>>>>>>>>> then I can enter in any Venue.
>>>>>>>>>
>>>>>>>>> Could somebody tell me what can happen?
>>>>>>>>
>>>>>>>>
>>>>>>>> Nico,
>>>>>>>>
>>>>>>>> Are the additional venues you've created actually visible to 
>>>>>>>> the client when the server is started from the init.d script?
>>>>>>>>
>>>>>>>> If not, then my guess is that whenever the server is started 
>>>>>>>> from the script in init.d directory, it is being run by the 
>>>>>>>> root user instead of the ordinary user who created the 
>>>>>>>> additional venue structure. In that case the server starts in 
>>>>>>>> the wrong directory and doesn't find the VenueServer.dat file 
>>>>>>>> that contains your venue structure (which was created when you 
>>>>>>>> ran the server as an ordinary user).
>>>>>>>>
>>>>>>>> Your init.d script should explicitly cd to the directory 
>>>>>>>> containing the correct VenueServer.dat file. It should also su 
>>>>>>>> to an ordinary user account to actually run the venue server.
>>>>>>>>
>>>>>>>> Here is the crucial line in our startup script which starts the 
>>>>>>>> server. You can see the cd to the directory which contains the 
>>>>>>>> VenueServer.dat file and if that succeeds it runs 
>>>>>>>> VenueServer3.py as the user 'ag' (not root).
>>>>>>>>
>>>>>>>>     cd /var/lib/ag/server_HALL && su ag -c 
>>>>>>>> /usr/bin/VenueServer3.py &
>>>>>>>>
>>>>>>>> Since you run Fedora, I think your executable will be just 
>>>>>>>> 'VenueServer' (rather than 'VenueServer3.py')
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> chris
>>>>>>>>
>>>>>>>>
>>>>>>>> Christoph Willing                       +61 7 3365 8350
>>>>>>>> QCIF Access Grid Manager
>>>>>>>> University of Queensland
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> Christoph Willing                       +61 7 3365 8350
>>>>>> QCIF Access Grid Manager
>>>>>> University of Queensland
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> Christoph Willing                       +61 7 3365 8350
>>>> QCIF Access Grid Manager
>>>> University of Queensland
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> Christoph Willing                       +61 7 3365 8350
>> QCIF Access Grid Manager
>> University of Queensland
>>
>>
>>
>>
>>
>
>
>




More information about the ag-tech mailing list