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