[
https://issues.apache.org/jira/browse/MAPREDUCE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988233#action_12988233
]
Todd Lipcon commented on MAPREDUCE-2289:
----------------------------------------
The central issue here is that the Java mkdir API doesn't take a mode, so
whenever we create a directory, it starts out with umask-based permissions
until we can call chmod on it.
Seems to me it would be safe and fix the race if we had it *fix* permissions if
they were wrong, rather than bailing out. Then the race would only cause a
redundant chmod. Thoughts?
> Permissions race can make getStagingDir fail on local filesystem
> ----------------------------------------------------------------
>
> Key: MAPREDUCE-2289
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2289
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: job submission
> Affects Versions: 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: 0.22.0
>
>
> I've observed the following race condition in TestFairSchedulerSystem which
> uses a MiniMRCluster on top of RawLocalFileSystem:
> - two threads call getStagingDir at the same time
> - Thread A checks fs.exists(stagingArea) and sees false
> -- Calls mkdirs(stagingArea, JOB_DIR_PERMISSIONS)
> --- mkdirs calls the Java mkdir API which makes the file with umask-based
> permissions
> - Thread B runs, checks fs.exists(stagingArea) and sees true
> -- checks permissions, sees the default permissions, and throws IOE
> - Thread A resumes and sets correct permissions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
