[GE users] Automated installation & BerkeleyDB

Marco Donauer Marco.Donauer at Sun.COM
Tue Apr 19 15:21:12 BST 2005


Alan,

yes, that right. It should be local directory on berkeley db server.
This is a bug in update 3. It will be also fixed in update 4.
The berkeley db installation doesn't care about existing spooldb 
directories.
=> the berkeley db server installation works well, but the qmaster 
installation finds
an existing spooldb directory with db files and stops.

Regards,
Marco

Alan Carriou wrote:

> Marco,
>
> thank you for your answer.
>
> I think I had stopped the servers and completely deleted the 
> directory, but I'll give it another try.
>
> > The autoinstallation stops, if the entered <sge-cell> or the spooldb
> > directory already exists.
> > This is done to make sure, that already installed clusters can't be
> > destroyed.
> But doesn't the BerkeleyDB installation create those directories too ? 
> Or should I place the spooldb directory for the BerkeleyDB host 
> elsewhere ?
>
>
> Best regards,
> Alan
>
> Marco Donauer wrote:
>
>> Hi Alan,
>>
>> no you are on the right mailing list!
>>
>> Before you started the second (fresh) installation did you delete 
>> your old spooldb directory?
>> The autoinstallation stops, if the entered <sge-cell> or the spooldb 
>> directory already exists.
>> This is done to make sure, that already installed clusters can't be 
>> destroyed.
>>
>> Please before restarting a autoinstallation check and delete the 
>> spooldb directory and the cell directory.
>> This is the most common reason, why the scripts fails.
>>
>> Your approach using the autoinstallation was right.
>>
>> First install the berkeley db insteractively, then use the 
>> autoinstallation to install qmaster and execd's
>>
>> Within the next few days the update 4 will be released and provides a 
>> better autoinstallation.
>> The berkeley db installation will be automatic also.
>>
>> Best Regards,
>> Marco
>>
>> Alan Carriou wrote:
>>
>>> Hi everybody,
>>>
>>> (disclaimer: It's my first mail on this mailing-list, so tell me if 
>>> it's not the good one)
>>>
>>> I have a problem using the automated installation with a BerkeleyDB for
>>> SGE 6.0u3.
>>>
>>> In our cluster, a NFS server, say host1, is set up, and exports 
>>> /sge-root/ to every computer. What we'd like to do is to use:
>>> - host1 as a Berkeley DB server,
>>> - another host, say host2, as the master host
>>> (and of course a few shadow and execution hosts)
>>> As the NFS is already a single point of failure, I guess installing 
>>> the BerkeleyDB on the same server won't be much harmful.
>>>
>>> When I try to install manually the master host, with "inst_sge -m" on
>>> host2, everything goes fine. I install the BerkeleyDB on host1 when 
>>> it tells me that I can, and it completes without any problem. Then I 
>>> set up some execution hosts with the automated installation, 
>>> everything's fine.
>>>
>>> But, as there are quite a few computers that we're going to use in the
>>> cluster, I'd prefer using the automated installation. So I tried it 
>>> on a fresh installation. As the manual tells me, I've first 
>>> installed the Berkeley DB on host1 with the interactive command 
>>> "inst_sge -db". I have put the spooldb directory in 
>>> /sge-root/testgrid/spooldb/. The server is alive, and seems to work.
>>>
>>> Then I wanted to use the automated procedure for the master and the
>>> execution hosts. So, I tried
>>>
>>> inst_sge -m -x -auto myfile.conf
>>>
>>> on host2. But the script fails with "The spooling directory 
>>> /sge-root/testgrid/spooldb/ already exists! Exiting installation!". 
>>> As the BerkeleyDB server has already been set up, the directory 
>>> indeed exists.
>>>
>>> So, either I am missing something, either there is a bug in the 
>>> automated installation. It seems that the installation of the master 
>>> host tries to create DB_SPOOLING_DIR locally, or at least checks is 
>>> presence, even if a BerkeleyDB is configured on a remote host.
>>>
>>> Should I set the spooldb DB_SPOOLING_DIR to another location, not 
>>> shared on the NFS ? Or have I forgotten something ?
>>>
>>> Thanks,
>>> Alan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list