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@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@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
>
>
>
>
>
