Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Exception in 2.0.0-beta2: "java.nio.file.AccessDeniedException: /var/cache/ldconfig" #13864

Closed
bcwilsondotcom opened this issue Sep 29, 2015 · 7 comments
Closed

Exception in 2.0.0-beta2: "java.nio.file.AccessDeniedException: /var/cache/ldconfig" #13864

bcwilsondotcom opened this issue Sep 29, 2015 · 7 comments

Comments

@bcwilsondotcom
Copy link

While trying to start up elasticsearch 2.0.0 beta2 I'm running into:

[2015-09-29 16:00:30,019][ERROR][org.elasticsearch.bootstrap] Exception
java.nio.file.AccessDeniedException: /var/cache/ldconfig
    at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
    at sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:426)
    at java.nio.file.Files.newDirectoryStream(Files.java:413)
    at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:179)
    at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:199)
    at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:199)
    at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:199)
    at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:69)
    at java.nio.file.Files.walkFileTree(Files.java:2602)
    at java.nio.file.Files.walkFileTree(Files.java:2635)
    at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:137)
    at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:86)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:154)
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:266)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
@rmuir
Copy link
Contributor

rmuir commented Sep 29, 2015

Why is this in your classpath?

@rmuir
Copy link
Contributor

rmuir commented Sep 29, 2015

And if you run with -Des.logger.level=DEBUG, you will get a lot of information, that might tell us why the system is misconfigured like that, the classpath shouldn't contain directories like that, that you don't have access to.

@bcwilsondotcom
Copy link
Author

Why is /var/cache/ldconfig in the classpath? It isn't as far as I can tell.

ES_CLASSPATH is ES_CLASSPATH=$ES_CLASSPATH:$ES_HOME/lib/*:$ES_HOME/lib/sigar/*

If I open up permissions on that dir it keeps trying to access various directories and fails with the same exception.

Directories it's complained about:

/var/cache/ldconfig
/var/lib/polkit-1
/var/lib/sudo

Also, I put -Des.logger.level=DEBUG into my elasticsearch-env.sh file and it doesn't appear to show any additional output in the log file.

@rmuir
Copy link
Contributor

rmuir commented Sep 30, 2015

You aren't running 2.0-beta2, but some frankenstein installation:

rmuir@beast:/Downloads/elasticsearch-2.0.0-beta2$ fgrep -r sigar .
rmuir@beast:/Downloads/elasticsearch-2.0.0-beta2$

@nik9000
Copy link
Member

nik9000 commented Sep 30, 2015

You aren't running 2.0-beta2, but some frankenstein installation:

Can you post the steps you took to get here?

rmuir added a commit to rmuir/elasticsearch that referenced this issue Sep 30, 2015
@rmuir
Fail hard on empty classpath elements.
415d897 
This can happen easily, if somehow old 1.x shellscripts survive and try to launch 2.x code.
I have the feeling this happens maybe because of packaging upgrades or something.
Either way: we can just fail hard and clear in this situation, rather than the current situation
where CWD might be /, and we might traverse the entire filesystem until we hit an error...

Relates to elastic#13864
@rmuir rmuir mentioned this issue Sep 30, 2015
Closed
rmuir added a commit that referenced this issue Sep 30, 2015
@rmuir
Nuke ES_CLASSPATH appending, JarHell fail on empty classpath elements
8c4bc7d 
Closes #13880

Squashed commit of the following:

commit 316a328
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:57:47 2015 -0400

    windows is terrible

commit 0406b56
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:43:09 2015 -0400

    Nuke ES_CLASSPATH appending

    Out of box, ES expects its stuff to be in particular places. We should not be appending to ES_CLASSPATH, allowing users to specify stuff there, like we do in elasticsearch.bin.sh

    If the user sets it, its not going to work out of box.

    Closes #13812

commit 415d897
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:26:35 2015 -0400

    Fail hard on empty classpath elements.

    This can happen easily, if somehow old 1.x shellscripts survive and try to launch 2.x code.
    I have the feeling this happens maybe because of packaging upgrades or something.
    Either way: we can just fail hard and clear in this situation, rather than the current situation
    where CWD might be /, and we might traverse the entire filesystem until we hit an error...

    Relates to #13864
rmuir added a commit that referenced this issue Oct 1, 2015
@rmuir
Nuke ES_CLASSPATH appending, JarHell fail on empty classpath elements
834c396 
Closes #13880

Squashed commit of the following:

commit 316a328
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:57:47 2015 -0400

    windows is terrible

commit 0406b56
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:43:09 2015 -0400

    Nuke ES_CLASSPATH appending

    Out of box, ES expects its stuff to be in particular places. We should not be appending to ES_CLASSPATH, allowing users to specify stuff there, like we do in elasticsearch.bin.sh

    If the user sets it, its not going to work out of box.

    Closes #13812

commit 415d897
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:26:35 2015 -0400

    Fail hard on empty classpath elements.

    This can happen easily, if somehow old 1.x shellscripts survive and try to launch 2.x code.
    I have the feeling this happens maybe because of packaging upgrades or something.
    Either way: we can just fail hard and clear in this situation, rather than the current situation
    where CWD might be /, and we might traverse the entire filesystem until we hit an error...

    Relates to #13864
rmuir added a commit that referenced this issue Oct 1, 2015
@rmuir
Nuke ES_CLASSPATH appending, JarHell fail on empty classpath elements
367e2e2 
Closes #13880

Squashed commit of the following:

commit 316a328
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:57:47 2015 -0400

    windows is terrible

commit 0406b56
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:43:09 2015 -0400

    Nuke ES_CLASSPATH appending

    Out of box, ES expects its stuff to be in particular places. We should not be appending to ES_CLASSPATH, allowing users to specify stuff there, like we do in elasticsearch.bin.sh

    If the user sets it, its not going to work out of box.

    Closes #13812

commit 415d897
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:26:35 2015 -0400

    Fail hard on empty classpath elements.

    This can happen easily, if somehow old 1.x shellscripts survive and try to launch 2.x code.
    I have the feeling this happens maybe because of packaging upgrades or something.
    Either way: we can just fail hard and clear in this situation, rather than the current situation
    where CWD might be /, and we might traverse the entire filesystem until we hit an error...

    Relates to #13864

Conflicts:
	core/src/main/java/org/elasticsearch/bootstrap/JarHell.java
rmuir added a commit that referenced this issue Oct 1, 2015
@rmuir
Nuke ES_CLASSPATH appending, JarHell fail on empty classpath elements
c4eeefb 
Closes #13880

Squashed commit of the following:

commit 316a328
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:57:47 2015 -0400

    windows is terrible

commit 0406b56
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:43:09 2015 -0400

    Nuke ES_CLASSPATH appending

    Out of box, ES expects its stuff to be in particular places. We should not be appending to ES_CLASSPATH, allowing users to specify stuff there, like we do in elasticsearch.bin.sh

    If the user sets it, its not going to work out of box.

    Closes #13812

commit 415d897
Author: Robert Muir <rmuir@apache.org>
Date:   Wed Sep 30 16:26:35 2015 -0400

    Fail hard on empty classpath elements.

    This can happen easily, if somehow old 1.x shellscripts survive and try to launch 2.x code.
    I have the feeling this happens maybe because of packaging upgrades or something.
    Either way: we can just fail hard and clear in this situation, rather than the current situation
    where CWD might be /, and we might traverse the entire filesystem until we hit an error...

    Relates to #13864

Conflicts:
	core/src/main/java/org/elasticsearch/bootstrap/JarHell.java

Conflicts:
	core/src/main/java/org/elasticsearch/bootstrap/JarHell.java
	core/src/test/java/org/elasticsearch/bootstrap/JarHellTests.java
@bcwilsondotcom
Copy link
Author

It looks like this was an issue caused by our config management system, chef in this case, mixing older ES 1.7 scripts with ES 2.0.

@clintongormley
Copy link

thanks for letting us know @bcwilsondotcom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@clintongormley @nik9000 @rmuir @bcwilsondotcom