Week of 170130

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: Sabine (Atlas), Julia A, Maarten, Ben (batch), Andrea M, Vincent, Kate (Chair), Alberto A, Vladimir (LHCb)
  • remote: Andrew, Christoph W (CMS), Di Quing, Dmytro, John Kelly (RAL), Pepe (PIC), Vincenzo (EGI), Dimitri (KIT), Mateo (CNAF)

Experiments round table:

  • ATLAS reports ( raw view) -
    • Smooth operation this week.
    • Jobs/Production: in average 250k job slots used (with a decrease to 200k at the beginning of the week), main effort concentrated on derivation production for analysis, simulation and analysis. Some of the derivation tasks are failing at the merging stage when 8 cores prod is used, the problem is known and fixed for new software tag. Overlay jobs test ongoing, their number is capped not to stress too much frontier servers, new software allowing to reduce the impact on databases is tested.
    • Data/Transfer: usual activity, some T2 data disk full are being clean up or rebalanced. Some sites were impacted by deletion errors due to the fact that not all SSL ciphers needed from CC7 are in their apache (zlcgdm-dav.conf) configuration file when using http (WebDav). GGUS have been sent to sites badly configured with the needed correction.
    • Services
      • Global CVMFS ATLAS CONDB partially on the whole week, ok since this weekend
      • Frontier services needed to be restarted at IN2P3-CC on Tuesday: atlasfrontier3-ai.cern.ch and atlasfrontier4-ai.cern.ch, because CERN nodes were configured with IPV6 by mistake and didnít accept new connections causing client to failover to IN2P3-CC.
      • AFS: ATLAS has some accidental afs use from grid jobs. If afs is not mounted then the libs are found elsewhere (in cvmfs). Question on what will happen on the no afs day, is there a possibility jobs hang ? see Jira ticket
        • We would like to test before A-day and ask for a volunteer site to block afs on the client side firewall.
        • Maarten commented that AFS references should be removed. Errors during disconnection tests can be expected, severity dependent on the client. Jan I. can be contacted about the tests timing. Vladimir added that AFS references are found in Root software. Maarten mentioned possible hang on timeout waits during the test.

  • CMS reports ( raw view) -
    • Had two crashes of CMS EOS headnode
    • CMS got informed about problems with 124 files on CASTOR tape
      • We are looking into what can be recovered from elsewhere and what needs to be declared lost (or where we want to attempt a vendor recovery)
    • Had issues with transfers to CERN over the weekend: GGUS:126242
      • Something went wrong with the proxy prolongation (on the CMS end)
      • Fixed already
    • Today an issue with parts of our Frontier infrastructure has popped up
      • Present investigations point to Oracle database
      • Experts are investigating

  • ALICE -
    • Very high activity in the last 2 days
    • CERN: HTCondor instabilities after upgrade (GGUS:126102, GGUS:126132)
    • CERN: site-bdii alias contained one bad host (GGUS:126099)
    • IN2P3-CC: CVMFS problem on ALICE VOBOX (GGUS:126249)
    • HTCondor status is explained in Ben's report below. Downgrade was necessary to make it usable.

  • LHCb reports ( raw view)
    • Activity
      • MC Simulation and user analysis
      • Site Issues
      • T0:
      • T1:
        • RAL: CVMFS problem (squid issue) (GGUS:126241); Fixed
        • GRIDKA: problems at ARC CEs (GGUS:126135)
          • LHCb is asking if it might be related to HTCondor issues. ALICE touched by HTCondor but has no issues with ARC CEs.

Sites / Services round table:

  • ASGC: nc
  • BNL: T1 network migration to a different firewalled zone, starting today at 16:00PM CERN time. Impact on user jobs and data transfers is expected to be minimum.
  • CNAF: Site downtime for core switch upgrade from 00:00 13/02 to 10:00 15/02 (CET)
  • EGI: ntr
  • FNAL: the FTS experienced an issue with a proxy that had legacy and RFC delegations mixed together
  • GridPP: nc
  • IN2P3: nc
  • KISTI: nc
  • KIT:
    • Issues with servers managed by the new, automatic system. Machines being rebooted or upgraded randomly. Under investigation.
    • Discussion on SAM Portal as a source for monitoring system for production. Maarten commented it's risky to alert experts based on external system. Pepe commented that the Nagios plugin used e.g. at PIC allows alarm thresholds to be defined for externally supplied metrics.
  • NDGF: One computing site is flapping up and down due to the filesystem problem. Is is working, but with interruptions.
  • NL-T1: On Thursday SURFsara will have an all-day (08:00 - 16:00 UTC) maintenance window for OS and dCache updates. For details see the GOCDB.
  • NRC-KI: nc
  • OSG: Data on site downtime proposal are being gathered.
  • PIC: ntr
  • RAL: Lingering problems with SAM tests for Alice after Thursday's upgrade of Castor. Castor team are looking into it. Still plan to do CMS Castor upgrade tomorrow. (31st Jan).

  • CERN computing services:
    • HTCondor CE instability after upgrade to 8.5.8. Downgraded to 8.5.6 and working with upstream.
  • CERN storage services:
    • FTS: upgrade to v3.5.8 + CentOS7.3 and SOAP dismissal planned for tomorrow (OTG:0035264).
  • CERN databases: Frontier issue caused by a bug in Oracle. Workaround applied, patch application will be discussed.
  • GGUS:
    • Last week's alarm tests went mostly OK
  • Monitoring:
    • Issue with UCSDT2 appearing three times in CMS VOFeed (as UCSDT2, UCSDT2-B, UCSDT2Sleep) is blocking the final availability reports for December (GGUS:125909)
  • MW Officer: NTR
  • Networks:
    • BNL to ASGC network performance under investigation by ESNet (ESNET-20170123-005)
  • Security: NTR


Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r22 - 2017-01-30 - 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-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