1. Gridice daemons are causing high load on CE machine. We had to switch off GridICE on several sites. (Central Europe)
2. Unable to edit pre-production report. (Central Europe)
3. Number of dteamsgm-enabled persons looks too high: 35! These people are mapped on one account and can have access to their proxies. It looks like VOM-RS config issue. (Central Europe)
4.Can we combine the production and PPS reports on the CIC portal? (CERN)
5.Problem raised by CSCS about ATLAS jobs:
We see a lot of 'silly' use of our resources. There are several jobs especially from ATLAS that will do some wide-area lcg-cp, with a timeout of 4000 seconds, retrying upon failure. This means that we have a lot of jobs sitting around in the timeout phase, sometimes for over 24 hours!! This is now being raised by our experiment contacts. The ATLAS computing model foresees no such pattern, actually the data is supposed to be copied to the computational site before the job is launched. So this is clearly bad practice (although the submitters seem to be members of the ATLAS production team). We are thinking of 'punishing' such bad practices by killing jobs with a CPU efficiency of < 60%.
What kind of experience do others have? Do any other sites see similar behavior? Is the "counter-measure" reasonable? (DCH)
6. PIC has a glite-CE deployed in production. What is the procedure for tracking a JobID inside the service logs? Given a local batch JobID we need a way to find out DN of the person that submitted this job. (South West Europe)
7. SFT failure times in CIC portal report do not match those on the tests page. (UK/I)
8. Is there a maximum rate at which LHCb job agents can obtain work? If so there is no point in sites excuting jobs any faster than this rate.
DETAIL: At times LHCb queue up to 200 jobs (no problem). Unfortuantly, when we are again ready to run LHCb jobs we find that of the 200 LHCb jobs that start imediatly only a handfull actually reach real execution. Most start and exit imediatly, presumably because they get no work from DIRAC.
Not a problem for site, but meens that other work queued with a lower priority now grabs the nodes which LHCb could have had if they had not had all exited imedietly. (UK/I)
