I essentially find the same as Owen just reported.
Should we be making another bug report?
Greig
On Fri, 8 Jul 2005, owen maroney wrote:
> And for IC we have:
>
> mapping
> "[log in to unmask]"
> edginfo
>
> login edginfo read-write 19491 19491 / / /
>
> [log in to unmask]
>
> So, I try replacing this with:
> > mapping "[log in to unmask]" edginfo
> >
> > login edginfo read-write 19491 19491 / / /
> > [log in to unmask]
>
> then
>
> su - edginfo
> > [edginfo@gfe02 edginfo]$ /opt/d-cache/srm/bin/srm-storage-element-info https://gfe02.hep.ph.ic.ac.uk:8443/srm/infoProvider1_0.wsdl
>
> produces stuff ending with:
>
> > StorageElementInfo :
> > totalSpace =2541546897408 (2481979392 KB)
> > usedSpace =30397658395 (29685213 KB)
> > availableSpace =2502704826621 (2444047682 KB)
>
> Hurrah! (although this will get overwritten at the next edg-mkgridmap
> update...)
>
> However, although now when I run, as edginfo:
> > [edginfo@gfe02 edginfo]$ /opt/lcg/libexec/lcg-info-dynamic-se
>
> I get a 3 second pause and output like:
> > dn: GlueSARoot=lhcb:/pnfs/hep.ph.ic.ac.uk/data/lhcb,GlueSEUniqueID=gfe02.hep.ph.ic.ac.uk,Mds-Vo-name=local,o=grid
> > GlueSAStateAvailableSpace: 2444047682
> > GlueSAStateUsedSpace: 37931710
>
> when I run, as edginfo, /opt/lcg/libexec/lcg-info-wrapper, it takes less
> than a second and produces output including:
> > GlueSAStateAvailableSpace: 00
> > GlueSAStateUsedSpace: 00
> in the output. I checked /opt/lcg/var/gip/tmp and the file
> lcg-info-dynamic-dcache.ldif.7010 is being updated but is only zero sized.
>
> So the output of the dynamic-se script does not seem to be getting
> incorporated into the output of the wrapper script.
>
> cheers,
> Owen.
>
> Alessandra Forti wrote:
> > no I have
> >
> > mapping
> > "[log in to unmask]"
> > edginfo
> >
> > login edginfo read-write 18948 18948 / / /
> >
> > [log in to unmask]
> >
> >
> > cheers
> > alessandra
> >
> > On Fri, 8 Jul 2005, Steve Traylen wrote:
> >
> >> On Thu, Jul 07, 2005 at 04:54:33PM +0100 or thereabouts, Philip Clark
> >> wrote:
> >>
> >>>
> >>>>
> >>>> I don't think we have a workaround, it just works?
> >>>>
> >>>> I expect you have mentioned it before but what is the problem?
> >>>
> >>>
> >>> http://savannah.cern.ch/bugs/?func=detailitem&item_id=8777
> >>>
> >>> We need to understand why you are not seeing this bug. IC, Manchester
> >>> and Edinburgh all seem to have it. If we try to monitor your storage
> >>> through the lcg information system then I expect it will show up too.
> >>
> >>
> >> Does your dcache.kpwd contain
> >>
> >> [log in to unmask]
> >>
> >>
> >> i.e are you seeing this one.
> >>
> >> https://savannah.cern.ch/bugs/?func=detailitem&item_id=5295
> >>
> >> but I'm sure I have already asked this question twice so feel free to
> >> scream if we are going through the same loop?
> >>
> >> Steve
> >>
> >>>
> >>> -Phil
> >>
> >>
> >> --
> >> Steve Traylen
> >> [log in to unmask]
> >> http://www.gridpp.ac.uk/
> >>
> >
>
>
--
=======================================================================
Greig Cowan e: [log in to unmask]
School of Physics t: +44 131 650 5300
The University of Edinburgh f: +44 131 650 7189
James Clerk Maxwell Building w: http://www.ph.ed.ac.uk/~gcowan1
Mayfield Road
Edinburgh
EH9 3JZ, UK
=======================================================================
|