Ah, OK, it's a permissions problem?  If memory serves, that should be
visible in the logs as well, but apparently not if you cancel them - or
maybe I missed it.

In resposne to your VOMS question, my suspicion is that the VOMS proxy
on the server will indeed die after the 23 hours, because the server
will have no means of renewing the VOMS proxy and it is telling you that
it is not bothering doing a renewal at this stage - this can only happen
through a MyProxy server and I am not even sure whether FTS will do this.

It looks like you will have to wait to within four hours of the expiry
of the server's proxy (so some 23-4 = 19 hours away) and then create a
new VOMS proxy - I am surprised you can get 72 hours but good if you can
- and then do another submission.

We will need to find a way around that; it is annoying to have to redo
this. People can normally accept one week, where it's the first thing
they do Monday morning. I would rather come up with (another) cunning
script using the robot certificate and have it renew the robot VOMS
proxy. Until we figure that out, I don't mind if you use a non-VOMS
proxy - I think you are currently the only one using the NIL VO :-)

BTW I am about to go on leave (tomorrow) for not less than two weeks
(and not more than three), so please make use of Brian in particular and
Sam, who are both on the list and are Highly Capable People™. Since I
haven't had 14 consecutive days off in eight years, I am under
instructions not to read email ... :-)

Cheers
--jens


On 20/07/2015 17:39, Lydia Heck wrote:
>
> Hi Jens,
>
> I am again and again caught out by this:
>
> I have a globus-online-setup file and in there I give explicit
> permission to access certain directories. And this one caught me out
> again.
>
> Lydia
>
>
> On Mon, 20 Jul 2015, Lydia Heck wrote:
>
>>
>> Hi Jens,
>>
>> I have not yet tried your script, but I have tried to submit the next
>> batch and I am stymied (again).
>>
>> I have a valid proxy
>> bash-4.1$ voms-proxy-info
>> subject   : /C=UK/O=eScience/OU=Durham/L=eScience/CN=lydia
>> heck/CN=Robot:GridClient/CN=proxy
>> issuer    : /C=UK/O=eScience/OU=Durham/L=eScience/CN=lydia
>> heck/CN=Robot:GridClient
>> identity  : /C=UK/O=eScience/OU=Durham/L=eScience/CN=lydia
>> heck/CN=Robot:GridClient
>> type      : full legacy globus proxy
>> strength  : 1024
>> path      : /tmp/x509up_u1378
>> timeleft  : 70:52:02
>> key usage : Digital Signature, Key Encipherment, Data Encipherment
>>
>> and when I submit the job(s) (4 of them to be precise), it looks as
>> if it starts, but then goes into retry mode.
>>
>> When I saw this I cancelled the four jobs.
>>
>> Any idea what could be wrong?
>>
>> Typical user comment: nothing has changed ....
>>
>> Lydia
>>
>>
>>
>> On Thu, 16 Jul 2015, Jensen, Jens (STFC,RAL,SC) wrote:
>>
>>> Right here's the script I came up with. It reads filenames (one per
>>> line) from stdin and puts them into files of customisable size and runs
>>> a command on each of those files. Gave me a quick excuse to do some
>>> Real
>>> Work™ but there may be other ways of doing the same thing. I have a
>>> feeling one could hack it with xargs.
>>>
>>> On 16/07/2015 09:57, Jensen, Jens (STFC,RAL,SC) wrote:
>>>> Hi Lydia,
>>>>
>>>> I guess the limit is for purposes of limiting the number of files
>>>> associated with a single transfer id for some sort of accounting or
>>>> debugging purposes.
>>>>
>>>> I was playing a bit with a script to do this but now need to go to a
>>>> meeting :-(
>>>>
>>>> Cheers
>>>> --jens
>>>>
>>>>
>>>> On 15/07/2015 17:06, Lydia Heck wrote:
>>>>> Hi Jens,
>>>>>
>>>>> Thank you for your inquiry.
>>>>>
>>>>> I have been thinking a lot about the transfers and was waiting for a
>>>>> colleague to combine some directories to reduce the number of files.
>>>>>
>>>>> I hit another limit:
>>>>>
>>>>> I can only create transfer instruction files with ~2048 entries. The
>>>>> next step was 4096 - somehow I am hooked on binary number - but
>>>>> fts-transfer-submit would not allow that.
>>>>>
>>>>> Then I it a user who has half a million files - quite small as
>>>>> well. I
>>>>> was asked by my DiRAC  colleagues if I could stream an tar
>>>>> instruction
>>>>> to fts-transfer-submit like
>>>>>
>>>>> tar cf - | xxxxxxxxx
>>>>>
>>>>> I have not asked that question, as I believe - from what I have seen
>>>>> of the command line - that this is not possible.
>>>>>
>>>>> So currently I am trying to figure out how best to deal with the
>>>>> situation of the limited submission files. Any idea there? How do
>>>>> other people deal with that?
>>>>>
>>>>> Lydia
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  On Wed, 15 Jul 2015, Jensen, Jens (STFC,RAL,SC) wrote:
>>>>>
>>>>>> Hi Lydia,
>>>>>>
>>>>>> Brian points out that RAL currently holds only about 82TB of DiRAC
>>>>>> data.  And this log currently shows very little activity:
>>>>>>
>>>>>> https://lcgfts3.gridpp.rl.ac.uk:8449/fts3/ftsmon/#/jobs?vo=&source_se=gsiftp:%2F%2Fdata.cosma.dur.ac.uk&dest_se=srm:%2F%2Fsrm-dirac.gridpp.rl.ac.uk&time_window=168
>>>>>>
>>>>>>
>>>>>>
>>>>>> Moreover we have 921 errors during the past week saying "file
>>>>>> already
>>>>>> exists and overwrite is not enabled"
>>>>>>
>>>>>> We are slightly worried that you are stuck/on leave/confused/busy
>>>>>> with
>>>>>> something else/unhappy/something different?
>>>>>>
>>>>>> Thanks
>>>>>> --jens
>>>>>>
>>>
>>