[
https://issues.apache.org/jira/browse/KUDU-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-3457:
--------------------------------
Description:
It seems that exceptions thrown from within {{RangerSubprocessMain.main()}}
isn't propagated to {{SubprocessServer}}. For example, when ranger-related
flags are specified, but {{\-\-keytab_file}} and/or {{\-\-principal}} flags are
missing, {{SubprocessServer::Init()}} still returns {{Status::OK()}}, while the
following message is printed into the stderr:
{noformat}
Exception in thread "main" org.apache.kudu.subprocess.KuduSubprocessException:
Kudu principal and Keytab file must be provided when Kerberos is enabled in
Ranger
at
org.apache.kudu.subprocess.ranger.authorization.RangerKuduAuthorizer.init(RangerKuduAuthorizer.java:78)
at
org.apache.kudu.subprocess.ranger.RangerProtocolHandler.<init>(RangerProtocolHandler.java:45)
at
org.apache.kudu.subprocess.ranger.RangerSubprocessMain.main(RangerSubprocessMain.java:39)
{noformat}
Apparently, {{SubprocessServer::StartSubprocessThread()}} takes care only of
starting the process, but it doesn't check whether {{SubprocessExecutor}} has
successfully started {{RangerProtocolHandler}}, so it's able to process at
least a single message. In the particular error scenario described above, the
sub-process exited immediately with non-OK status, but that wasn't detected.
It's necessary to detect early stage errors like that, so
{{SubprocessServer::Init()}} would return non-OK status in case if
{{RangerProtocolHandler}} hasn't started or isn't able to process a single
message right after the start.
was:
It seems that exceptions thrown from within {{RangerSubprocessMain.main()}}
isn't propagated to {{SubprocessServer}}. For example, when ranger-related
flags are specified, but {{\-\-keytab_file}} and/or {{\-\-principal}} flags are
missing, {{SubprocessServer::Init()}} still returns {{Status::OK()}}, while the
following message is printed into the stderr:
{noformat}
Exception in thread "main" org.apache.kudu.subprocess.KuduSubprocessException:
Kudu principal and Keytab file must be provided when Kerberos is enabled in
Ranger
at
org.apache.kudu.subprocess.ranger.authorization.RangerKuduAuthorizer.init(RangerKuduAuthorizer.java:78)
at
org.apache.kudu.subprocess.ranger.RangerProtocolHandler.<init>(RangerProtocolHandler.java:45)
at
org.apache.kudu.subprocess.ranger.RangerSubprocessMain.main(RangerSubprocessMain.java:39)
{noformat}
Apparently, {{SubprocessServer::StartSubprocessThread()}} takes care only of
starting the process, but it doesn't check whether {{SubprocessExecutor}} has
successfully started {{RangerProtocolHandler}}, so it's able to process at
least a single message. In that particular error scenarios described above,
the sub-process exited immediately with non-OK status, but that wasn't detected.
It's necessary to detect early stage errors like that, so
{{SubprocessServer::Init()}} would return non-OK status in case if
{{RangerProtocolHandler}} isn't started or isn't able to process a single
message right after the start.
> An error from RangerSubprocessMain isn't propagated to system catalog (master)
> ------------------------------------------------------------------------------
>
> Key: KUDU-3457
> URL: https://issues.apache.org/jira/browse/KUDU-3457
> Project: Kudu
> Issue Type: Bug
> Components: master, ranger
> Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0, 1.16.0, 1.17.0
> Reporter: Alexey Serbin
> Priority: Major
>
> It seems that exceptions thrown from within {{RangerSubprocessMain.main()}}
> isn't propagated to {{SubprocessServer}}. For example, when ranger-related
> flags are specified, but {{\-\-keytab_file}} and/or {{\-\-principal}} flags
> are missing, {{SubprocessServer::Init()}} still returns {{Status::OK()}},
> while the following message is printed into the stderr:
> {noformat}
> Exception in thread "main"
> org.apache.kudu.subprocess.KuduSubprocessException: Kudu principal and Keytab
> file must be provided when Kerberos is enabled in Ranger
> at
> org.apache.kudu.subprocess.ranger.authorization.RangerKuduAuthorizer.init(RangerKuduAuthorizer.java:78)
> at
> org.apache.kudu.subprocess.ranger.RangerProtocolHandler.<init>(RangerProtocolHandler.java:45)
> at
> org.apache.kudu.subprocess.ranger.RangerSubprocessMain.main(RangerSubprocessMain.java:39)
> {noformat}
> Apparently, {{SubprocessServer::StartSubprocessThread()}} takes care only of
> starting the process, but it doesn't check whether {{SubprocessExecutor}} has
> successfully started {{RangerProtocolHandler}}, so it's able to process at
> least a single message. In the particular error scenario described above,
> the sub-process exited immediately with non-OK status, but that wasn't
> detected.
> It's necessary to detect early stage errors like that, so
> {{SubprocessServer::Init()}} would return non-OK status in case if
> {{RangerProtocolHandler}} hasn't started or isn't able to process a single
> message right after the start.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
