hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Roling (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10015) UserGroupInformation prints out excessive ERROR warnings
Date Mon, 17 Jul 2017 18:39:00 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090304#comment-16090304
] 

Ben Roling commented on HADOOP-10015:
-------------------------------------

Just as a note for convenience to users of Cloudera's distribution - they have reverted this
change in CDH5:
https://github.com/cloudera/hadoop-common/commit/4051b9b7865b8485584346992f23cae1de0bc4e2

I've opened a case with them to see why as I was mislead by WARN messages produced by UserGroupInformation
and had to spend some time looking into something that really wasn't an issue.

> UserGroupInformation prints out excessive ERROR warnings
> --------------------------------------------------------
>
>                 Key: HADOOP-10015
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10015
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 3.0.0-alpha1
>            Reporter: Haohui Mai
>            Assignee: Nicolas Liochon
>            Priority: Minor
>             Fix For: 2.4.0
>
>         Attachments: 10015.v3.patch, 10015.v4.patch, 10015.v5.patch, 10015.v6.patch,
HADOOP-10015.000.patch, HADOOP-10015.001.patch, HADOOP-10015.002.patch
>
>
> In UserGroupInformation::doAs(), it prints out a log at ERROR level whenever it catches
an exception.
> However, it prints benign warnings in the following paradigm:
> {noformat}
>  try {
>         ugi.doAs(new PrivilegedExceptionAction<FileStatus>() {
>           @Override
>           public FileStatus run() throws Exception {
>             return fs.getFileStatus(nonExist);
>           }
>         });
>       } catch (FileNotFoundException e) {
>       }
> {noformat}
> For example, FileSystem#exists() follows this paradigm. Distcp uses this paradigm too.
The exception is expected therefore there should be no ERROR logs printed in the namenode
logs.
> Currently, the user quickly finds out that the namenode log is quickly filled by _benign_
ERROR logs when he or she runs distcp in secure set up. This behavior confuses the operators.
> This jira proposes to move the log to DEBUG level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message