Yep, we had just got ourselves back together after the morning's
network rejiggy. Then I had the bright idea of upgrading us whilst we
were still in downtime.
With luck this won't impact users and jobs too much, as they use the
lcg-tools, although it is annoying. Have the developers been informed?
If not I can mail them.
cheers,
Matt
On 31/01/2008, Greig Alan Cowan <[log in to unmask]> wrote:
> Matt, I need to leave now, so can't really look into this anymore. Was
> this all working prior to your upgrade?
>
> Greig
>
> On 31/01/08 16:09, Matt Doidge wrote:
> > Hello,
> > I'm having fun and games with an upgrade to 1.8.0-12p4 too. Seems
> > naked srmcp fails in exactly the same way as Greig sees. Lcg-cp and
> > srmcp with explicitly set port ranges work. I didn't change the
> > dcachesetup file with the upgrade, and only upgraded the
> > srm/poolmanager node- not the gridftp door nodes- although all nodes
> > got a restart after the upgrade.
> >
> > cheers,
> > Matt
> >
> > On 31/01/2008, Greig Alan Cowan <[log in to unmask]> wrote:
> >> Hi all,
> >>
> >> I've upgraded the Edinburgh dCache to 1.8.0-12p4. Everything seemed to
> >> go fine, apart from the fact that I now can't use srmcp to copy files
> >> out. g-u-c and lcg-cp are fine. In the srmcp case it is becasue the pool
> >> is trying to connect to a port on the client machine that is outside of
> >> the defined GLOBUS_TCP_PORT_RANGE. In the guc and lcg-cp cases, it is
> >> the client that is connecting to the pool or door, which is fine. Anyone
> >> else seen this?
> >>
> >> If I run the client with the port range defined explicitely, it works:
> >>
> >> srmcp -1 -debug -globus_tcp_port_range=50000,52000
> >> srm://srm.epcc.ed.ac.uk:8443/pnfs/epcc.ed.ac.uk/data/lhcb/1201621959
> >> file:////tmp/test4
> >>
> >> Has there been a change in how the port range should be defined
> >> (50000,52000 or 50000:52000 or 50000 52000)?
> >>
> >> Cheers,
> >> Greig
> >>
>
|