[
https://issues.apache.org/jira/browse/HADOOP-13223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15310052#comment-15310052
]
Steve Loughran edited comment on HADOOP-13223 at 6/1/16 12:03 PM:
------------------------------------------------------------------
Normally JIRA titles this negative are viewed as a bit rude, but here I think
we can all agree you are merely stating the problem and the ideal solution in
the title. Maybe for the release notes the title could be rephrased "winutils
killed with an axe —for its own good".
I wasn't aware that MapR bundled something what wasn't quite ASF
{{WINUTILS.EXE}}in their bunding of what-isn't-Apache Hadoop. Makes sense,
though it is painfully reminiscent of AOL's bundling of their own
{{WINSOCK.DLL}}; yes, it added TCP-over-AOL dial, up, but broke TCP everywhere
else.
Which brings me round to this; DLLs are just as bad as EXEs for getting on the
path then ruining your life —and can often be even more brittle at load. I say
that as someone whose first introduction to windows coding was actually
Windows/386. That doesn't mean it's not needed, just that it's not a silver
bullet.
Having multiple WINUTILs versions on the PATH is probably going to break you
either way. You've just got encounter this because the rest of us who setup and
run ASF-based windows installations (or cloud-hosted versions) do operate a
one-release-only process so haven't hit the same path-of-pain as you.
And as you note, Hadoop isn't helpful enough when things don't work. We've done
our best with networking, and Kerberos diagnostics is now an ongoing bit of
work (HADOOP-12649).
In HADOOP-10775 we put effort in to making failures to find winutils useful,
* stack traces are more meaningful than an NPE in process launch
* problems are only logged at time of use, not the time that the {{Shell}}
class is instantiated. Like you say: a distraction otherwise.
* we try to include a bit more on the cause of failure (no {{HADOOP_HOME}}, no
{{WINUTILS.EXE}}, etc
* the messages point to a wiki entry on the topic
https://wiki.apache.org/hadoop/WindowsProblems
* which points to where I've been building windows binaries off the ASF
commits. https://github.com/steveloughran/winutils
* we're explicitly picking up the winutils file from
{{%HADOOP_HOME%/BIN/WINUTILS.EXE}}
* And you can set the system property {{hadoop.home.dir}} to point to a hadoop
home of your choice.
I hope you can agree, this will make life less painful, though it sounds like
your multi-install setup may expose you to problems we haven't hit ourselves.
# Can you download & build a windows version of 2.8.0 to see how well the new
codepath works for you? As before we ship that is the time to improve it
# You can add more details onto that WindowsProblems wiki page —create an
account on the hadoop wiki, then ask on the dev list (or email me me direct)
for write access. This can be done after the 2.8.x release
There's not much we can do about the MapR codebase, other than mention it on
the WindowsProblems wiki page.
You have made me realise one thing; we could look at adding a way to verify
that the winutils version is compatible. At the very least, we should be
printing some version info and the path where it is, so that a {{WINUTILS
version}} will tell you what's causing needless pain.
And, finally; yes, let's get the axe out and take it behind the shed, never to
be seen again. Contributions there *are* welcome.
was (Author: [email protected]):
Normally JIRA titles this negative are viewed as a bit rude, but here I think
we can all agree you are merely stating the problem and the ideal solution in
the title. Maybe for the release notes the title could be rephrased "winutils
killed with an axe —for its own good".
I wasn't aware that MapR bundled something what wasn't quite ASF {{WINUTILS.EXE
}}in their bunding of what-isn't-Apache Hadoop. Makes sense, though it is
painfully reminiscent of AOL's bundling of their own {{WINSOCK.DLL}}; yes, it
added TCP-over-AOL dial, up, but broke TCP everywhere else.
Which brings me round to this; DLLs are just as bad as EXEs for getting on the
path then ruining your life —and can often be even more brittle at load. I say
that as someone whose first introduction to windows coding was actually
Windows/386. That doesn't mean it's not needed, just that it's not a silver
bullet.
Having multiple WINUTILs versions on the PATH is probably going to break you
either way. You've just got encounter this because the rest of us who setup and
run ASF-based windows installations (or cloud-hosted versions) do operate a
one-release-only process so haven't hit the same path-of-pain as you.
And as you note, Hadoop isn't helpful enough when things don't work. We've done
our best with networking, and Kerberos diagnostics is now an ongoing bit of
work (HADOOP-12649).
In HADOOP-10775 we put effort in to making failures to find winutils useful,
* stack traces are more meaningful than an NPE in process launch
* problems are only logged at time of use, not the time that the {{Shell}}
class is instantiated. Like you say: a distraction otherwise.
* we try to include a bit more on the cause of failure (no {{HADOOP_HOME}}, no
{{WINUTILS.EXE}}, etc
* the messages point to a wiki entry on the topic
https://wiki.apache.org/hadoop/WindowsProblems
* which points to where I've been building windows binaries off the ASF
commits. https://github.com/steveloughran/winutils
* we're explicitly picking up the winutils file from
{{%HADOOP_HOME%/BIN/WINUTILS.EXE}}
* And you can set the system property {{hadoop.home.dir}} to point to a hadoop
home of your choice.
I hope you can agree, this will make life less painful, though it sounds like
your multi-install setup may expose you to problems we haven't hit ourselves.
# Can you download & build a windows version of 2.8.0 to see how well the new
codepath works for you? As before we ship that is the time to improve it
# You can add more details onto that WindowsProblems wiki page —create an
account on the hadoop wiki, then ask on the dev list (or email me me direct)
for write access. This can be done after the 2.8.x release
There's not much we can do about the MapR codebase, other than mention it on
the WindowsProblems wiki page.
You have made me realise one thing; we could look at adding a way to verify
that the winutils version is compatible. At the very least, we should be
printing some version info and the path where it is, so that a {{WINUTILS
version}} will tell you what's causing needless pain.
And, finally; yes, let's get the axe out and take it behind the shed, never to
be seen again. Contributions there *are* welcome.
> winutils.exe is an abomination and should be killed with an axe.
> ----------------------------------------------------------------
>
> Key: HADOOP-13223
> URL: https://issues.apache.org/jira/browse/HADOOP-13223
> Project: Hadoop Common
> Issue Type: Improvement
> Components: bin
> Affects Versions: 2.6.0
> Environment: Microsoft Windows, all versions
> Reporter: john lilley
>
> winutils.exe was apparently created as a stopgap measure to allow Hadoop to
> "work" on Windows platforms, because the NativeIO libraries aren't
> implemented there. Rather than building a DLL that makes native OS calls,
> the creators of winutils.exe must have decided that it would be more
> expedient to create an EXE to carry out file system operations in a
> linux-like fashion. Unfortunately, like many stopgap measures in software,
> this one has persisted well beyond its expected lifetime and usefulness. My
> team creates software that runs on Windows and Linux, and winutils.exe is
> probably responsible for 20% of all issues we encounter, both during
> development and in the field.
> Problem #1 with winutils.exe is that it is simply missing from many popular
> distros and/or the client-side software installation for said distros, when
> supplied, fails to install winutils.exe. Thus, as software developers, we
> are forced to pick one version and distribute and install it with our
> software.
> Which leads to problem #2: winutils.exe are not always compatible. In
> particular, MapR MUST have its winutils.exe in the system path, but doing so
> breaks the Hadoop distro for every other Hadoop vendor. This makes creating
> and maintaining test environments that work with all of the Hadoop distros we
> want to test unnecessarily tedious and error-prone.
> Problem #3 is that the mechanism by which you inform the Hadoop client
> software where to find winutils.exe is poorly documented and fragile. First,
> it can be in the PATH. If it is in the PATH, that is where it is found.
> However, the documentation, such as it is, makes no mention of this, and
> instead says that you should set the HADOOP_HOME environment variable, which
> does NOT override the winutils.exe found in your system PATH.
> Which leads to problem #4: There is no logging that says where winutils.exe
> was actually found and loaded. Because of this, fixing problems of finding
> the wrong winutils.exe are extremely difficult.
> Problem #5 is that most of the time, such as when accessing straight up HDFS
> and YARN, one does not *need* winutils.exe. But if it is missing, the log
> messages complain about its absence. When we are trying to diagnose an
> obscure issue in Hadoop (of which there are many), the presence of this red
> herring leads to all sorts of time wasted until someone on the team points
> out that winutils.exe is not the problem, at least not this time.
> Problem #6 is that errors and stack traces from issues involving winutils.exe
> are not helpful. The Java stack trace ends at the ProcessBuilder call. Only
> through bitter experience is one able to connect the dots from
> "ProcessBuilder is the last thing on the stack" to "something is wrong with
> winutils.exe".
> Note that none of these involve running Hadoop on Windows. They are only
> encountered when using Hadoop client libraries to access a cluster from
> Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
