kubectl get pods -n abc
NAME READY STATUS RESTARTS AGE
abc-v2-78b59ccc4f-85xgr 0/1 CrashLoopBackOff 27 129m
Facing below error:
> ➜ ~ kubectl logs -f abc-v2-78b59ccc4f-85xgr -n
Error: Unable to access jarfile abc.jar
I am assuming either jar is not present or required access is missing.
Pls guide me here, how to proceed.
Edit 1: As suggested by #howard-roark, Jar is available inside container, getting the same error message.
Edit 2: Check results now with .jar in java command
Edit 4: Ideally there should be only one instance with running status.
Kubernetes is a Container Orchestrator. It runs your images as Containers. The error you are showing looks like an application error and not a Kubernetes error. The way I would approach this is:
Check if the jar file your application calls is in your image. You can do this locally by running your image and exec'ing in to see if your jar file that your application runs is there.
docker run -it <image> /bin/bash
Or you can do a similar command via Kubernetes to exec into your pod:
kubectl run -i --tty testjavacontainer --image=<image> -- /bin/bash
If it is there, then I would confirm its path and make sure that my java command is correctly referencing that path. If it is not there, then I would adjust my Dockerfile to ensure it is at the path that my java command expects.
In short, I would approach this as a standard java error, with the nuance that it happens to run in a container.
Related
I switched from distroless/java:8 to distroless/java:8-debug container and, when deployed to kubernetes, I started getting following error:
Error: Unable to access jarfile /MyApp-0.1.jar
This is my Dockerfile:
FROM gcr.io/distroless/java:8-debug
LABEL CONTAINER_NAME=my-api
ARG JAR_FILE=MyApp/core/build/libs/core-0.1-boot.jar
COPY ${JAR_FILE} MyApp-0.1.jar
ENTRYPOINT ["java","-jar","/MyApp-0.1.jar"]
While I was using regular distroless (everything else was the same) I didn't have this problem.
What is interesting is that when I try to run this Dockerfile locally, I don't get this error. Is this some permission issue?
I redeployed and it is working now. The only logical explanation is that I tried to use nonroot one first and when I switched to root one, some of the pods with nonroot were still there causing the problem.
From what I gathered from this build script:
https://github.com/GoogleContainerTools/distroless/blob/main/java/BUILD
Both of those containers are identical. only the debug one includes java compiler
Also, you could try running the app from the container itself. Run something similar to this:
docker run -it --entrypoint sh my-api
running the whoami inside the container verifies that the user is root, so no restrictions should exist
I want to run the testng.xml file in Jenkins. I am using the custom workspace and I added Execute Shell as a build step.
I am writing the following command to Execute Shell:
java -cp "./*:bin" org.testng.TestNG testng.xml
All the required jar files and testng.xml file is inside /home/wonderbiz/Documents/JarFolder
When I am clicking on build now I am getting this exception.
Run command as a root user or
Change the permission of the root directory that you want to access e.g. here /home/wonderbiz/Documents/JarFolder
so use command
$ sudo su
# chmod -R 777 /home
But i would recommend you to create own directory and then modify the permission of that directory.
e.g.
# mkdir /demo
Copy required file to that directory(/demo) and do the configuration setting then try to run.
This error message...
java.nio.file.AccessDeniedException: /home/wonderbiz/Documents
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.checkAccess(UnixFileSystemProvider.java:308)
at java.nio.file.Files.createDirectories(Files.java:746)
at hudson.FilePath.mkdirs(FilePath.java:3239)
...implies that the Jenkins was unable to access/create the sub-directory /home/wonderbiz/Documents.
This issue can raise in either/all of the below mentioned cases:
checkAccess error is generally caused because of either insufficient permissions or someother process locking the file. In this usecase it seems that the folder that Jenkins unsuccessfully tried to access was already present. The folder and all the files beneath were present even before the execution was triggered.
Parent directory (/home/wonderbiz/Documents) needs to have at least rx for non-owner to list its content and w to make changes there, regardless of subdirectory permissions. Change the permission of the /home/wonderbiz/Documents/JarFolder directory
chmod -R 777 /home
A better approach would have to create dedicated directory eg. in /opt and use that.
This problem can also ocurr because Jenkins don't have permission to execute job with in /home/wonderbiz/Documents sub-directory. Go to Jenkins Config file (Red Hat - /etc/sysconfig/jenkins), and see which user you are using to run Jenkins). To solve this you need to change the owner of jobs to the jenkins user:
sudo chown -R jenkins:jenkins /home/wonderbiz/Documents (need to restart Jenkins)
It appears like the os user which is running jenkins has no write privileges for either the complete workspace directory or some of the files in the workspace directory.
Outro
You can find a relevant discussion in Need correct step for Bat file creation using (TestNG.xml + Maven)
I have a small java web app (grails), deployed under tomcat 8, from which I would like to execute a script on the local server using sudo. On a regular debian/ubuntu server all I have to do is use visudo to allow the tomcat user to execute sudo without a password on that particular script, and everything works as expected. When I tried installing the same war file on the raspberry pi (model 3b+, raspbian 10 - buster), booting from an SD card, the execution of the script always fails with the error "sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges'.
In an effort to track down this issue I have written another small executable jar that performs the same function (i.e. attempts to launch the script using sudo). This test program works as expected when logged in interactively (bash) as both the 'pi' and 'tomcat8' users (I had to set a shell for the tomcat8 user to order to get an interactive login). I then used strace to try and diagnose the issue. All I could glean from that is that getuid() is returning 111 (tomcat8) when trying to launch sudo when running under the tomcat8 service, but will return 0 when running in bash.
I have also written a small c program that simply calls getuid() and prints the result. If I run it under the tomcat8 user interactively (i.e. sudo su tomcat8), it prints '111' when I run it without sudo, and '0' when I run it with sudo. When I try and launch this program from the web-app (using process builder) I get '111' when the command is run without sudo, but I get the 'effective uid is not 0 ...' error when the command is prefixed with sudo.
I have checked mount, and there are a number of mounts with the 'nosuid' attribute, but not the root '/' directory where /usr/bin is located, and /usr/bin/sudo looks to have the correct permissions:
pi#raspberrypi:~/dev $ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 147560 Jan 13 2019 /usr/bin/sudo
In desperation I have tried a couple of other things to just see what effect they might have:
* Added the tomcat8 user to adm, sudo and other groups
* Attempted to remount the other mounts without the nosuid attribute, although I couldn't remount about 6 or so because the mounts where in use.
Neither of these appeared to have any effect.
So it seems to me that the tomcat8 user can use sudo when in bash, but not when running as a daemon. Can anyone give me some ideas as to what is going on here? Is there anyway to diagnose or trace how an effective uid is determined by the os?
Other things that may be significant:
I installed both openjdk-8-jdk and tomcat8 via apt, and even though raspbian uses systemd, tomcat8 is launched via an init.d script. Not sure if this is causing uid issues.
If it is the SD card having some mounts with the nosuid attribute causing the problem, why doesn't it fail when running interactively?
It turns out it was an issue with the way the daemon is started, probably due to changes in the way Debian 10 starts daemon processes. I removed the tomcat init.d script, and replaced it with a systemd unit file, and included the following properties:
[Service]
...
NoNewPrivileges=false
AmbientCapabilities=CAP_SETGID CAP_SETUID
SecureBits=keep-caps
This allows the daemon to actually call setUid(0) successfully.
I am trying to put a piece of open source software in a docker container (https://github.com/att/XACML) but in this container I can not use maven. The documentation for running this service says to use mvn jetty, which does work fine, but in order to get this in a container I don't want to include a build step (maven).
Instead, I'd like a way to compile the a war, so I can copy just the war into the container and execute it from there.
I have tried many attempts to get the war running without maven jetty but none of them work.
java -jar /path/to/jar
no main manifest attribute error. There is no main class, it extends an HttpServlet
using jetty-runner
when I launch the war with jetty-runner through the command line I do not get any errors, but it boots up to a page showing the directory of files, and not the actual project.
Making an 'uber-jar' to package all deps
same issue as 1, get a no main manifest issue.
I can include more code if that would be helpful (pom files etc), but I don't want to add too much if it is unneeded. I am super unfamiliar with how java projects are packaged and deployed, so I am having a difficult time figuring out what needs to be done.
Thanks!
Minimal Dockerfile to work with your webapp / war file is ...
FROM jetty:9.4.18
ADD ROOT.war /var/lib/jetty/webapps/
This uses the official jetty docker image at
https://hub.docker.com/_/jetty
Managed at
https://github.com/eclipse/jetty.docker
The name ROOT.war is special, and will deploy your webapp in the "root" context path of "/"
Building Image
If you build it like this ...
$ docker build -t stackoverflow/jetty:latest .
Running Image
Interactively (so you can the logs)
$ docker run --interactive --tty --rm --publish 80:8080 stackoverflow/jetty:latest
As Daemon
$ docker run --detach --publish 80:8080 stackoverflow/jetty:latest
The server will be available on port 80 of the machine you ran the docker run command on.
Configuring Jetty Base
If you need to configure the jetty image you can use any of the standard start.jar commands.
Example:
FROM jetty:9.4.18
WORKDIR $JETTY_BASE
RUN java -jar $JETTY_HOME/start.jar --add-to-start=jsp
ADD ROOT.war /var/lib/jetty/webapps/
How This Works Without Maven
See the official image details ...
https://github.com/eclipse/jetty.docker/blob/master/9.4-jdk11/Dockerfile
The key commands are ...
WORKDIR $JETTY_BASE
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["java","-jar","/usr/local/jetty/start.jar"]
I get Error: Unable to access jarfile jar-runner.jar when trying to run my jar.
Dockerfile:
FROM anapsix/alpine-java
MAINTAINER bramhaag
CMD ["java", "-jar", "jar-runner.jar", "some param", "some param"]
The jar file is located in /home/selfbot/ and I'm running this with Portainer.
This is what my Portainer container looks like:
How would I make this work?
With CMD [ ] "exec" format, Docker will try to look at the arguments and give its opinion about their usefulness. "Unable to access jarfile" is a Docker message, and it just means Docker has some (unspecified) issues with a jarfile. I've encountered it when the name of the jarfile contained an ENV variable, for instance. Docker couldn't handle that, apparently.
There's also the CMD "shell" format, CMD java -jar jar-runner.jar "some param" "some param". This is known as the shell format because Docker hands of the arguments to /bin/sh -c. As a result, it's not trying to second-guess what the arguments mean. sh in turn doesn't try to be smart either. And java is entirely capable of using jar-runner.jar.
Mind you, if you've got a typo in jar-runner.jar, or you put it in the wrong location, then Docker's message might be right. The shell workaround is useful when Docker guesses wrong.
It looks like you have the volume mounted, so assuming that you are correct that the jar file is available in the container via that volume, you probably just need to specify the path to it so java can find it.
CMD ["java", "-jar", "/home/selfbot/jar-runner.jar", "some param", "some param"]
You can check whether the file is really available by running a different command to just show you the contents of a given directory. Change the command (in Portainer) to something like
ls -la /home/selfbot
And then you can verify whether the jar file is actually where you think it, whether it is readable, etc. This command will exit right away, but its output will be available in the container log.
Try ENTRYPOINT ["java","-jar","jar-runner.jar"]
CMD ["some param"]
I had a similar issue here on my post: Error: Unable to access jarfile when running docker container