Hi Min,
On Mon, 11 Apr 2005, Min Tsai wrote:
> Hi Szabolcs,
>
> You can change the "giis url" in the gocdb for you site and this will update
> the Giis monitor query as well. However there may a delay of up to 30
Thanks. I did not know that. Done.
> minutes since this information is cached. I can clear this cache to make
> the transition faster, if you let me know when the change is made.
>
> Btw, there are new scripts that check the status of rgma:
> http://grid-deployment.web.cern.ch/grid-deployment/documentation/LCG2-Site-T
> esting/LCG2-Site-Testing.html#SECTION00060000000000000000
Thanks again, I'll check that as well
Cheers,
Szabolcs
>
> Cheers,
> Min
>
> -----Original Message-----
> From: LHC Computer Grid - Rollout [mailto:[log in to unmask]] On
> Behalf Of Laurence
> Sent: Monday, April 11, 2005 12:02 PM
> To: [log in to unmask]
> Subject: Re: [LCG-ROLLOUT] LCG-2_4_0 problems after upgrading
>
> 1. GIP
>
> There is no yaim function that configures the condor batch system. You
> will need to create the script /opt/lcg/libexec/lcg-info-dynamic-ce
> yourself. This is a wrapper script that calls the dynamic plugin for
> condor with all the arguments etc. There is a new condor dynamic plugin
> that contains a number of bug fixes in the release.
>
>
> 3. R-GMA
> Can you check what version of R-GMA you have installed, you should have
>
> edg-rgma-api-java-4.0.2-1
>
> Service Status is now published via
>
> /etc/rc.d/init.d/edg-rgma-servicetool
>
> not the script that your trying to start. The old rgam rpms should have
> been removed when you upgraded.
>
>
> Hernath Szabolcs wrote:
>
>> Dear List,
>>
>> here are a few notes on the problems experienced while/after upgrading to
>> 2_4_0 from 2_3_1 (OS is/was SLC) with yaim:
>>
>> 1. GIP
>>
>> /opt/lcg/var/gip/lcg-info-generic.conf (on the CE) has been configured to
>> use the dynamic script /opt/lcg/libexec/lcg-info-dynamic-ce, but there is
>> no such file on our system (which package owns this file?). In earlier
>> versions, where lcg-info-dynamic-condor was configured, the invocation
>> was
>> incorrect (the correct form is 'lcg-info-dynamic-condor <condor_bin_path>
>> <config_file>'). I do not know whether this has been corrected, as yaim
>> did not configure it this time. The lcg-info-dynamic-condor script itself
>> was somewhat buggy in 2_3_1 - again, I do not know if it has been
>> corrected, as our own corrected version did not get overwritten.
>>
>> 2. JM
>>
>> As already pointed out by Gergely Debreczeni, the jobmanager invocation
>> (/opt/globus/etc/grid-services/jobmanager-lcgcondor) lacks the critical
>> condor-arch (and the not-so critical condor-os) options.
>>
>> 3. R-GMA
>>
>> Well, apart from the fact that it still does not work :-),
>> /etc/init.d/edg-rgma-service-status complains about the missing files
>> /opt/edg/etc/rgma/rgma-defaults and
>> /opt/edg/etc/rgma/rgma-tools-defaults.
>> How should these be created?
>>
>> /opt/edg/sbin/test/edg-rgma-check and edg-rgma-run-examples only
>> complained about the ServiceStatus applet, but I can't check them right
>> now, as there seems to be a problem with the registry...
>>
>> 4. Monitoring
>>
>> As already announced earlier, our infosys contact string has been changed
>> to
>>
>> ldap://grid109.kfki.hu:2170/mds-vo-name=BUDAPEST,o=grid
>>
>> The gstat monitoring, however, still tries to query
>>
>> ldap://grid109.kfki.hu:2135/mds-vo-name=budapestlcg2,o=grid
>>
>> thus we have been getting an "ERROR" state lately (Min, could you please
>> change that?).
>>
>> The lcg testzone reports still show yesterday's results for our site,
>> whereas other sites seem to have been running the tests today as well.
>> Any
>> reason for that? The new set of CA rpms still seem to spoil the test
>> (the UK eScience md5sum thing) and so mark a critical test as failed.
>>
>> Regards,
>>
>> Szabolcs Hernath
>>
>
|