Bug #71

Error "FAILED: failed permission denied" when waiting for array jobs

Added by Alejandro Lorca over 2 years ago. Updated about 2 years ago.

Status:Closed Start date:2009-10-30
Priority:High Due date:
Assignee:Eduardo Huedo % Done:

100%

Category:-
Target version:5.6.0 Estimated time:6.00 hours

Description

In version 5.5.0 it may happen that in a multiuser instance, the user cannot wait for his own array jobs

$ gwwait -A 1
FAILED: failed permission denied

but it gives no problem when waiting for each of the jobs independently.

The problem comes originally from the proxy_path that, strangely, behaves differently for array jobs than for jobs. The user gets some trash as proxy_path and is declined the right for waiting for those jobs simultaneously.

Associated revisions

Revision 187
Added by Alejandro Lorca over 2 years ago

Fixed proxy_path comparison (check issue #71).

Revision 188
Added by Alejandro Lorca over 2 years ago

Comparison performed over pointers, corrected (check issue #71).

Revision 190
Added by Alejandro Lorca over 2 years ago

Comparison in proxy_path pointer improved (issue #71).
Log dir of released locks from gw_im_mad_egee_ldap changed to info file.

Revision 191
Added by Eduardo Huedo over 2 years ago

Proper initialization of proxy_path (issue #71).

Revision 193
Added by Eduardo Huedo over 2 years ago

Proper initialization of proxy_path (issue #71).

Revision 194
Added by Eduardo Huedo about 2 years ago

Initialization of proxy_init (issue #71).

Revision 234
Added by Eduardo Huedo over 1 year ago

Copy proxy_path as long string (bug #71).

History

Updated by Alejandro Lorca over 2 years ago

The source of the problem is related to the client proxy_path, not being empty when running in multiuser case, for array jobs

Updated by Alejandro Lorca over 2 years ago

  • Status changed from Assigned to Resolved
  • Target version changed from 5.6.0 to 5.5.1
  • % Done changed from 20 to 100

The fix is done through a comparison of strings at ''src/client/gw_client_init.c''.
Now both, multi- and single-user instances behave correctly.

Updated by Alejandro Lorca over 2 years ago

  • Status changed from Resolved to Closed

Testing has been performed successfully.

Updated by Alejandro Lorca about 2 years ago

  • Assignee changed from Alejandro Lorca to Eduardo Huedo
  • Target version changed from 5.5.1 to 5.6.1

Updated by Alejandro Lorca about 2 years ago

  • Target version changed from 5.6.1 to 5.6.0

Fix will be ready in version 5.6.0.

Also available in: Atom PDF