Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "DMSU topics gridops meeting"

From EGIWiki
Jump to navigation Jump to search
Line 30: Line 30:
# fix the documentation
# fix the documentation
# try to deploy the workaround automatically when NSS-poisoned system is detected
# try to deploy the workaround automatically when NSS-poisoned system is detected
'''UPDATE Nov 19th''': the


== Grid Operations Meeting 5th November 2012 ==
== Grid Operations Meeting 5th November 2012 ==

Revision as of 12:20, 19 November 2012

Grid Operations Meeting 19th November 2012

FTS jobs abort with "No site found for host xxx.yyy" error

Details GGUS #87929

From time to time, some FTS transfers fail with the message above. The problem was reported at CNAF, IN2P3, and GRIDKA, noticed by Atlas, CMS, and LHCb VOs. The problem is appearing and disappearing in rather short and unpredictable intervals.

Exact reasons are not yet understood, we keep investigating. Reports from sites affected by similar problem will be appreciated.

LCMAPS-plugins-c-pep in glexec fails at RH6 based WNs

Details GGUS #88520

Due to replacement of OpenSSL with NSS in the RH6 based distributions, LCMAPS-plugins-c-pep invoked from glexec fails on talking to Argus PEP via curl.

This is a known issue, as mentioned in EMI glexec release notes however, the workaround is not described in a usable way there.

Once we make sure we understand it properly and that the fix works, it will be documented properly at UMD pages and passed to the developers to

  1. fix the documentation
  2. try to deploy the workaround automatically when NSS-poisoned system is detected

UPDATE Nov 19th: the

Grid Operations Meeting 5th November 2012

problem in retrieving the job output after EMI2 update 4 (WMS)

for details see GGUS 87802

it seems that if an user never used the myproxy and he isn't currently using it, she can retrieve the output without any problem. For the other kind of users, the problem occurrs (see the details in that ticket).

  • the user proxy is usually stored in the Sandboxdir, but if the user is using the myproxy service, that file is a symlink to the real file stored in the proxy renewal directory (/var/glite/spool/glite-renewd). When the jobs ends, that proxy is purged so that the user hasn't any more the permissions to retrieve the output
  • For the moment a simple workaround is to submit a new job, and before its ending, retrieve the output of any previous job.

Moreover it was also noticed that if in the jdl there isn't the variable related to myproxy, in the jdl stored in the Sandboxdir it is wrongly contained that variable set to the myproxy hostname that is set by default on the UI. Instead if in the jdl it is present an empy variable like the following:

  MyProxyServer = "";

the jdl stored on the WMS will properly contain it, the proxy is stored in the SandBoxDir (no symlink to proxy renewal dir) and the user is able to retrieve the output when the job ends.

UPDATE Nov 13th: there is a workaround, reported also in the known issues section of "EMI2 update 4" page. Besides this update is currently in the UMD staged rollout phase.