[AG-TECH] Problems with Access Grid 3.0.2
Nico
nmolina at cesga.es
Wed Oct 24 04:25:45 CDT 2007
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