Week of 161024

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.

Tier-1 downtimes

Experiments may experience problems if two or more of their Tier-1 sites are inaccessible at the same time. Therefore Tier-1 sites should do their best to avoid scheduling a downtime classified as "outage" in a time slot overlapping with an "outage" downtime already declared by another Tier-1 site supporting the same VO(s). The following procedure is recommended:

  1. A Tier-1 should check the downtimes calendar to see if another Tier-1 has already an "outage" downtime in the desired time slot.
  2. If there is a conflict, another time slot should be chosen.
  3. In case stronger constraints cannot allow to choose another time slot, the Tier-1 will point out the existence of the conflict to the SCOD mailing list and at the next WLCG operations call, to discuss it with the representatives of the experiments involved and the other Tier-1.

As an additional precaution, the SCOD will check the downtimes calendar for Tier-1 "outage" downtime conflicts at least once during his/her shift, for the current and the following two weeks; in case a conflict is found, it will be discussed at the next operations call, or offline if at least one relevant experiment or site contact is absent.

Links to Tier-1 downtimes




  • local: Kate D-W (chair and minutes), Ivan Glushkov (ATLAS), Maarten Litmaath (ALICE), Vincent Brillault (Security), Luca Mascetti (Storage), Alexei (LHCb), Alberto Aimar (Monitoring), Julia Andreeva (WLCG), Hugo (Storage), Gavin McCance (Computing), Andrea Manzi (MW), Marian Babik (Network),
  • remote: FaHui Lin (ASGC), Xin Zhao (BNL), Luca Lama and Antonio Falabella (CNAF), Vincenzo Spinoso (EGI), John Kelly (FNAL), Rolf Rumler (IN2P3), Victor Zhiltsov (JINR), Xavier Mol (KIT), Andrew Pickford and Alexander Verkooijen (NL-T1), Di Qing (TRIUMF), Jean Roch (CMS), Eygene Ryabinkin (NRC-KI), Hiro (PIC), Hiro Ito (BNL), Dennis van Dok (NL-T1), Sang-Un (KISTI), Ulf (NDGF)

Experiments round table:

  • ATLAS reports ( raw view) -
    • Frontier overload pinned down to DCS pixel high voltage monitoring and calibration data loaded for each event which is not needed in production at all.

  • CMS reports ( raw view) -
    • T0 back-log build-up from high luminosity : being addressed
      • Sure to get to 40/fb this year !
    • Running an average 130K core last week
      • Data reprocessing over xrootd with limited capabilities in E.U. : trying harder and across to U.S.
      • Issue LHCONE in moscow : T1_RU_JINR => GGUS:124500
      • KIT storage upgrade.
      • Adding GGUS reporting lines for opportunistic NERSC => GGUS:124599 (OSG, ...)

  • ALICE -
    • NTR

  • LHCb reports ( raw view) -
    • Activity
      • Monte Carlo simulation, data reconstruction/stripping and user jobs on the Grid
    • Sites
      • RRCKI - very slow transfers caused by network problems, more then 100 hours data backlog (GGUS:124538)

Sites / Services round table:

  • ASGC: On 18 Oct. the raid controller of one storage array broken. Controller replaced, but still one partition of data (~20TB) not accessible, causing some job failures and file transfer issues last week. Tried to repair and rescue data but still lost this partition. Will claim data loss.
  • BNL: ntr
  • CNAF:
    • Reminder scheduled down:
      • 2nd november: 8 hours for firmware update of various HW components of disk storage system affected: ATLAS(disk), ALICE(disk) and AMS(disk)
      • 3d november: 8 hours for firmware update of various HW components of disk storage system affected: ALL TAPE
  • EGI:ntr
  • FNAL: ntr
  • GridPP:ntr
  • IN2P3: CVE-2016-5195 : CentOS7 / RHEL7 machines accessible from outside are down (all non WLCG); planning actions for older systems (EL6...). Downtimes possible with short notice.
  • JINR: Networking got better, but some LHCONE issues still exist. The problem is expected to be resolved in a couple of days.
  • KISTI:ntr
  • KIT:
    • Downtime on short notice for ATLAS, CMS and LHCb tomorrow from 08:30 to 09:30 UTC for a network intervention that isolates the dCache databases. When everything goes according to plan, we will finish much earlier.
    • For a yet unknown reason, both storage controllers of one server rack rebooted simultaneously on Friday 11 am. Because of this, nearly half of LHCb's disk-only data was inaccessible for about 3 hours, tape archived data has not been retrievable since. Still working on this.
  • NDGF:
    • dcache headnodes updated for dirtycow, the reboot triggered a bug in dcache that then got fixed.
    • 2 clusters online (patched for dirtycow already) and two waiting to be updated.
  • NL-T1:
    • SARA datacenter move follow-up:
      • Bandwidth issue: this is now understood; not a network issue but a false CPU governor/speed setting combined with iperf3 using only one core.
      • Compute cluster: still running at reduced capacity; no solution expected soon.
    • Planning actions to mitigate CVE-2016-5195 ("dirty cow"); possibly a downtime on short notice. Comment: downtime rather avoidable
  • NRC-KI:
    • rebuilding external network after router failure: found out that the current L2 exchange capacity between stack members at M9 is insufficient, applying temporary workaround (as we speak, work started 16:00 MSK today and will finish no later than 16:40 MSK) to eliminate the bottleneck.
    • in the view of CVE-2016-5195 (DirtyCOW), we will be rebooting all our WNs into the patched kernel today or tomorrow.
  • OSG: ntr
  • PIC: ntr
  • RAL: A response to dirty cow is being discussed. Most probably a full downtime for the whole data center.

  • CERN computing services:
    • CVE-2016-5195 mitigation installed on interactive and batch compute nodes, notably disabling any functionality that requires ptrace (e.g. gdb).
    • Kernel patch will be rolled out once fully available from Redhat: expect some long running jobs to be terminated in order to recover properly patched capacity in a reasonable timescale.
    • Major datacentre network upgrade planned for November 2nd 07.00 - 09.30
  • CERN storage services: Extent of the network intervention to be assessed
  • CERN databases: Extent of the network intervention to be assessed
  • GGUS: ntr
  • Monitoring:
  • MW Officer: ntr
  • Networks: ntr
  • Security: CVE-2016-5195 is becoming more and more critical:


Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r22 - 2016-11-09 - MaartenLitmaath
    • 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-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback