|Main||EGI.eu operations services||Support||Documentation||Tools||Activities||Performance||Technology||Catch-all Services||Resource Allocation||Security|
|Documentation menu:||Home •||Manuals •||Procedures •||Training •||Other •||Contact ►||For:||VO managers •||Administrators|
Back to Troubleshooting Guide
Cannot take token!
$ glite-wms-job-logging-info -v 2 https://wms221.cern.ch:9000/hFtw9svc7vBkj3GnvCHwOJ [...] Event: Done [...] - Exit code = 1 [...] - Reason = Cannot take token! - Source = LogMonitor [...] - Status code = FAILED [...]
The token is a file in the job's input sandbox area on the WMS: if the job wrapper can successfully remove the token, it knows there cannot be another instance of the job running somewhere else (without such a check the uniqueness cannot be fully guaranteed). Therefore, by default the wrapper needs to be able to remove the token or else it will exit and the job may be retried elsewhere. To remove the token the job wrapper tries these commands in order:
$GLITE_LOCATION/bin/glite-gridftp-rm # obsolete `which glite-gridftp-rm` # obsolete $EDG_LOCATION/bin/edg-gridftp-rm # obsolete `which edg-gridftp-rm` # obsolete $GLOBUS_LOCATION/bin/uberftp `which uberftp`
The operation would fail if "uberftp" cannot be found or does not work. The wrapper will only try to remove the token after the download of the real input sandbox has succeeded, which would mean the Globus configuration on the WN was in good shape and should also work for "uberftp".
The user can disable this feature by adding ShallowRetryCount = -1 (not 0) to the JDL as a workaround, at the expense of disabling shallow retries of failed jobs. In general it is recommended to keep shallow retries enabled, because they normally increase the job success rate significantly by skipping over broken CEs.