Week of 150622

WLCG Operations Call details

  • At CERN the meeting room is 513 R-068.

  • For remote participation we use the Vidyo system. Instructions can be found here.

General Information

  • The purpose of the meeting is:
    • to report significant operational issues (i.e. issues which can or did degrade experiment or site operations) which are ongoing or were resolved after the previous meeting;
    • to announce or schedule interventions at Tier-1 sites;
    • to inform about recent or upcoming changes in the experiment activities or systems having a visible impact on sites;
    • to provide important news about the middleware;
    • to communicate any other information considered interesting for WLCG operations.
  • The meeting should run from 15:00 until 15:20, exceptionally to 15:30.
  • The SCOD rota for the next few weeks is at ScodRota
  • General information about the WLCG Service can be accessed from the Operations Web
  • Whenever a particular topic needs to be discussed at the daily meeting requiring information from site or experiments, it is highly recommended to announce it by email to wlcg-operations@cernSPAMNOTNOSPAMPLEASE.ch to make sure that the relevant parties have the time to collect the required information or invite the right people at the meeting.

Monday

Attendance:

  • local: Luca (Storage+SCOD), Ilija (ATLAS), Raja (LHCb), Maarten (ALICE), Ignacio (Batch), Lorena (DB)
  • remote: Oliver (CMS), Michael (BNL), Felix (ASGC), Lisa (FNAL), Onno (NLT1), Pavel (KIT), Tiju (RAL), Sonia (CNAF), Jose (PIC)

Experiments round table:

  • ATLAS reports (raw view) -
    • Overview, Central Services, Tier-0/Tier1s
      • SARA-MATRIX full disk issue - due to problems with Rucio. Understood and getting fixed. GGUS:114519
      • AGLT2 transfers failures - under investigation. GGUS:114510
      • INFN-T1 - FTS transfers from and to INFN-T1 seem to be failing. Probably issue of misunderstanding between FTS and Storm. GGUS:114522
      • general FTS issue: when a large number of files is waiting to be transferred, submissions to it become very slow. For an example see: GGUS:114512

  • CMS reports (raw view) -
    • Some files seem not to migrate to CASTOR tape at CERN: GGUS:114282
      • was identified to be a CMS problem (wrong file class used)
      • Apologies for the noise.
    • File transfer issues from FNAL to RAL: GGUS:114275
      • RAL NOC is investigating a potential problem within RAL
    • Tape staging test at CERN ongoing: GGUS:114283

  • ALICE -
    • very high activity
      • 80k concurrent jobs from Sun evening until Mon afternoon!
    • CERN: 2.5% raw data reco failures due to CVMFS problems (team ticket GGUS:114534)

  • LHCb reports (raw view) -
    • Mostly user jobs on the grid
    • T0
    • T1
      • NTR
    • T2
      • Files stored without checksums at various sites - GGUS ticketing individual sites (one-time request to fix the problem). Affects Nipne (GGUS:114526) and CPPM (GGUS:114527)
    • Others
      • Dirac issue this morning affected all users, leading to job failures across the grid. Recovered now.

Sites / Services round table:

  • ASGC: NTR
  • BNL: NTR
  • CNAF: NTR
  • FNAL: NTR
  • GridPP:
  • IN2P3:
  • JINR:
  • KISTI:
  • KIT: NTR
  • NDGF:
  • NL-T1:
    • Last friday srm overloaded by a non-cern user GGUS:114478 , similar issue happened in march (GGUS:112413), problem due to a bug in srm-ifce, solved after upgrading the library.
    • Tomorrow transparent intervention to perform maintenance on the power infrastructure.
  • NRC-KI:
  • OSG: NTR
  • PIC: NTR
  • RAL: NTR
  • TRIUMF:

  • CERN batch and grid services:
    • MyProxy running on CERN CentOS7 and a new filer since this morning at 11:30 (see OTG0022399 for details).
      • We're still seeing connections being established (but terminated at application level with an error) on the old SLC6 nodes from alicluster.if.pw.edu.pl. Please verify local DNS cache and/or target host when connecting to MyProxy at CERN (it should be myproxy.cern.ch).
  • CERN storage services:
  • Databases:
  • GGUS:
  • Grid Monitoring:
  • MW Officer:

AOB:

  • Warning: next meeting will be held in building 31 room S-028

Thursday

Attendance:

  • local: Luca (SCOD+Storage), Ken (CMS), Raja (LHCb), Lorena (DB)
  • remote: David (ATLAS), Dennis (NLT1), Di Qing (TRIUMF), Gareth (RAL), Felix (ASGC), Rolf (IN2P3), Jens (NDGF), Thomas (KIT), Torsten, Lucia (CNAF)

Experiments round table:

  • ATLAS reports (raw view) -
    • Usual activity, bulk reprocessing of run-2 data started. Nothing else to report

  • CMS reports (raw view) -
    • Pretty quiet out there; we continue to run plenty of MC production and some analysis, sometimes at high levels but not so much today.
      • Some data files from T0 were lost because they were too large (30 GB and bigger) to go into the storage system.
    • GGUS tickets of note:
      • GGUS:114553 -- xrootd global redirector got stuck. It wasn't noticed by a shifter, which means that we need to improve the monitoring on this. (Wasn't noticed by CERN IT either.) Daemons were restarted along with the redirector and that fixed it. We asked for the logs to understand why; I'm not sure they've been provided yet.
      • GGUS:114554 -- file read problems at T1_US_FNAL. It came down to a bug somewhere (lcmpaps plugins, if I understand right) about how sockets are handled. Rolled back to earlier RPM, working on debugging.
      • GGUS:114557 -- ce04 in unknown state at CERN. tomcat restarted.

  • ALICE -
    • high activity

Sites / Services round table:

  • ASGC: NTR
  • BNL:
  • CNAF: NTR
  • FNAL:
  • GridPP:
  • IN2P3: NTR
  • JINR:
  • KISTI:
  • KIT: NTR
  • NDGF: Next Thursday 4h downtime for dCache upgrade
  • NL-T1:
    • Yesterday at SARA just before 12:00 CEST a user (the same as last week) had opened 3600 concurrent getfilerequests, and at the same time we observed all incoming traffic drop to almost zero. This happened with the srm-ifce bug fix installed. It appears that the timeout is now 300 seconds enforced by the client instead of the 2 hours we have configured in dCache, but when there is a surge in activity the SRM can still be overloaded, even when the limit that we have set in dCache is not reached. We have asked the user to bypass the SRM for his file operations for now to work around this issue. We think this issue has caused a discrepancy between files and space reservations that we need to investigate.
  • NRC-KI:
  • OSG: CPU accounting numbers were published incorrectly (20 times higher), now fixed.
  • PIC:
  • RAL: 2 short networking issue on Tuesday afternoon
  • TRIUMF:

  • CERN batch and grid services:
  • CERN storage services:
  • Databases:
  • GGUS:
    • GGUS release done on wednesday. 3 new SU ( OpenStack-OCCI, WLCG Network Throughput and US CMS T3). 'Grid Monitoring' SU visible on submission form. Minor fixes on UI.
      • All test alarms were acknowledged correctly
  • Grid Monitoring:
    • ATLAS request for recomputation: GGUS:114067 Closed
    • ATLAS request for recomputation: GGUS:114182 Closed
    • LHCB and CMS request for recomputation: GGUS:114099 Closed
    • Final availability reports for May sent, and available at the SAM3 UI
  • MW Officer:

AOB:

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r14 - 2015-06-25 - LucaMascetti
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback