We have this user's jobs running at Liverpool as well, but as with
RAL-LCG2, he's a biomed user.
Same issue with the excessive sleep times (up to 1539720!) and since
the user currently has 369 jobs running here, it's a fairly large issue.
The line in their script causing the sleep is:
sleep `expr $N_RUN \* 60`
N_RUN is set by the first argument to their script, which in this case
is 25662, hence, it ends up executing 'sleep 1539720'.
As I understand it, according to the inefficient job policy we should
ticket the user and we can delete these jobs immediately since the
reason for the effective stalling of the job is obvious?
Rob
Phil Roffe wrote:
> User DN is...
> dteam019 /c=it/o=infn/ou=personal certificate/l=cnaf/cn=luciana
> carota
>
> As Jeremy commented, I suspect this is simply a mistake and is not
> supposed to be run as dteam. Though it is the sleep 669720 seconds that
> got me concerned.
>
> Phil
>
> Ewan MacMahon wrote:
>>> -----Original Message-----
>>> From: Testbed Support for GridPP member institutes [mailto:TB-
>>>
>>> Yes, we've seen the same at RAL-LCG2 and were about to do the same but
>>> got distracted by the security incident - but its not a dteam user its
>>> a biomed user.
>>>
>>>
>> What would really help clarify things here is the user's DN; that way
>> you'll
>> be able to tell if it's actually the same guy getting (wrongly?) mapped
>> to
>> different VOs, and everyone else will be able to check their logs.
>>
>> Ewan
>>
>
--
Robert Fay [log in to unmask]
System Administrator office: 210
High Energy Physics Division tel (int): 43396
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 3396
University of Liverpool http://www.liv.ac.uk/physics/hep/
|