We Keep Coding

Syntax error: "(" unexpected when running Docker container

This is my Dockerfile:
# Setup Inst
FROM ubuntu:latest
MAINTAINER test
LABEL maintainer="test"
RUN mkdir /srv/papermc
WORKDIR /srv/papermc
# Install OpenJDK-17
RUN apt-get update && \
apt-get install -y openjdk-17-jre-headless && \
apt-get install -y ant && \
apt-get install -y screen && \
apt-get install -y wget && \
apt-get clean;
# Fix certificate issues
RUN apt-get update && \
apt-get install ca-certificates-java && \
apt-get clean && \
update-ca-certificates -f;
# Setup JAVA_HOME -- useful for docker commandline
ENV JAVA_HOME /usr/lib/jvm/java-17-openjdk-amd64/
RUN export JAVA_HOME
# Download PAPERMINECRAFT
RUN wget https://api.papermc.io/v2/projects/paper/versions/1.19.3/builds/363/downloads/paper-1.19.3-363.jar
# STOP
STOPSIGNAL SIGTERM
# ENV
ENV TYPE=VANILLA VERSION=1.19.3 EULA="" UID=1000 GID=1000 RCON_PASSWORD=paper
# Prepare RUN
EXPOSE 25565 25575
VOLUME /srv/papermc
RUN echo "screen -AmdS minecraft java -Xms1024M -Xmx1024M -jar /srv/mcvanilla/paper-1.19.2-220.jar nogui" > start
RUN chmod -R 775 /srv/papermc
ENTRYPOINT ["/bin/sh"]
CMD start
HEALTHCHECK none
It is building without errors, but if I try to start the container, I get the following error:
Successfully tagged papermc:latest
root#docker3:~# docker run papermc
/bin/sh: 2: Syntax error: "(" unexpected
I was expecting a Java error because of not accepting the EULA, but not this one. What could be wrong?

Your ENTRYPOINT/CMD setup is wrong. You should simplify the end of the file to
# ...do the installation steps...
ENV TYPE=VANILLA VERSION=1.19.3 EULA="" UID=1000 GID=1000 RCON_PASSWORD=paper
CMD java -Xms1024M -Xmx1024M -jar /srv/mcvanilla/paper-1.19.2-220.jar nogui
and then docker run papermc will start the server without requiring you to log in, start a screen session, or anything else.
As #CharlesDuffy hints in a comment, if you're just wrapping a single process, Docker and Screen have some similarities and it's unusual to use Screen in a container. You can view the docker logs of the container and, in the unusual event you need to interact with the process's stdin, docker attach to it.
What's actually happening in your case deals with the way string-form CMD is converted to an actual command-word array and then combined with ENTRYPOINT. The documentation on Dockerfile ENTRYPOINT has details on these mechanics. As you've written it, the single command the container runs is
/bin/sh /bin/sh -c 'start'
which in turn causes the shell to try to execute the /bin/sh binary as a shell script, passing it arguments -c and start as the positional variables $1 and $2. When /bin/sh is an ELF binary and not itself a shell script, you get a parse error like this.

How to make shell visible to java in docker container

I am trying to run jython.sh from my Docker container and below are the Jython and Java versions.
We really need to suppress this error, this is very misleading and looks messy. This error is displayed before the execution of every call to Jython and looks like it cannot find the shell.
Is there a way I can fix the error/exception thrown below?
How to make shell visible to java in docker?
Commands used:
docker run -d <image_name>
docker exec -it <container_name> bash
Dockerfile
FROM alpine:latest
ARG IMAGE_NAME
ENV PATH=$PATH:/bin:/opt/user/jre/bin
ENV LIBRARY_PATH=$LIBRARY_PATH:/opt/user/jre/lib/amd64/server:/opt/user/jre/lib/amd64/jli:/opt/user/jre/lib/amd64
USER user
VOLUME /opt/user/etc/
VOLUME /var/log/user
EXPOSE 6800
ENTRYPOINT ["/bin/bash", "/opt/user/bin/startup.sh", "user"]
#startup.sh script contains some container specific initialization
System requirements
Jython 2.7.1 (default:0df7adb1b397, Jun 30 2017, 19:02:43)
[OpenJDK 64-Bit Server VM (AdoptOpenJDK)] on java1.8.0_292
Type "help", "copyright", "credits" or "license" for more information.
Actual result
$ ./jython.sh
[ERROR] Failed to construct terminal; falling back to unsupported
java.io.IOException: Cannot run program "sh": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at org.python.jline.internal.TerminalLineSettings.exec(TerminalLineSettings.java:308)
at org.python.jline.internal.TerminalLineSettings.stty(TerminalLineSettings.java:282)
at org.python.jline.internal.TerminalLineSettings.get(TerminalLineSettings.java:143)
at org.python.jline.internal.TerminalLineSettings.<init>(TerminalLineSettings.java:108)
at org.python.jline.internal.TerminalLineSettings.getSettings(TerminalLineSettings.java:123)
at org.python.jline.UnixTerminal.<init>(UnixTerminal.java:60)
at org.python.jline.UnixTerminal.<init>(UnixTerminal.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.python.jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
at org.python.jline.TerminalFactory.create(TerminalFactory.java:102)
at org.python.jline.TerminalFactory.get(TerminalFactory.java:186)
at org.python.jline.TerminalFactory.get(TerminalFactory.java:192)
at org.python.jline.console.ConsoleReader.<init>(ConsoleReader.java:243)
at org.python.util.JLineConsole.install(JLineConsole.java:107)
at org.python.core.Py.installConsole(Py.java:1744)
at org.python.core.PySystemState.initConsole(PySystemState.java:1269)
at org.python.core.PySystemState.doInitialize(PySystemState.java:1119)
at org.python.core.PySystemState.initialize(PySystemState.java:1033)
at org.python.core.PySystemState.initialize(PySystemState.java:989)
at org.python.core.PySystemState.initialize(PySystemState.java:984)
at org.python.util.jython.run(jython.java:263)
at org.python.util.jython.main(jython.java:142)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:247)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 26 more
Jython 2.7.1 (default:0df7adb1b397, Jun 30 2017, 19:02:43)
[OpenJDK 64-Bit Server VM (AdoptOpenJDK)] on java1.8.0_292
Type "help", "copyright", "credits" or "license" for more information.
>>>
Expected result
$ ./jython.sh
Jython 2.7.1 (default:0df7adb1b397, Jun 30 2017, 19:02:43)
[OpenJDK 64-Bit Server VM (AdoptOpenJDK)] on java1.8.0_292
Type "help", "copyright", "credits" or "license" for more information.
>>>
Working environment
However, I'm able to run Jython without any error/exception with Alpine image & OpenJDK8
Dockerfile
FROM alpine:latest
RUN apk update && apk add --no-cache openjdk8 \
&& apk add --no-cache bash \
bash-5.1$ ./jython.sh
Jython 2.7.1 (default:0df7adb1b397, Jun 30 2017, 19:02:43)
[OpenJDK 64-Bit Server VM (IcedTea)] on java1.8.0_302
Type "help", "copyright", "credits" or "license" for more information.
>>>

The Alpine distribution does not come with bash, but a lightweight shell called ash.
From there on, you have two possibilities, either your script is simple enough to be executed by ash, and you can adapt your shebang and usage accordingly, or, you install bash in your Alpine container.
So, either, in your script:
#!/usr/bin/env ash
echo 'I work'
Or, in your Dockerfile
FROM alpine:latest
RUN apk add --no-cache bash
# the rest of your container comes here
If your script does confuse sh for bash, what you could also do is to change the shell where /bin/sh points, which is, per default /bin/busybox by changing the symlink of /bin/sh, this way:
FROM alpine:latest
RUN apk add --no-cache bash \
&& ln -sf /bin/bash /bin/sh
# the rest of your container comes here
And that is actually what you are doing already in the other container that you said is working
FROM alpine:latest
RUN apk update && apk add --no-cache openjdk8 \
&& apk add --no-cache bash
### ^--- Here you are installing bash
Extra note: apk update is not needed when installing packages with the --no-cache flag.
Worth reading: Alpine Dockerfile Advantages of --no-cache Vs. rm /var/cache/apk/*

Update gitlab JDK to JDK17 (VM doesn't have internet connection)

I am using Gitlab to build a Java tool using ant
The tool requires JDK 17, but ant JDK version is 11, and I'm trying to change it.
So I tried a lot of solutions using a remote repository or remote download site, but after some tries I found out that the VM used to build the tool is not connected to internet (trying to ping google or my IP address doesn't work).
So I tried to upload in the same package with the tool source code the JDK 17 (openjdk-17_linux-x64_bin.tar.gz) and install it there.
Here is the problem, I am not sure how to do this since I don't work with linux, but I tried almost everything on the internet.
Every of these commands are used in a .gitlab-ci.yml file, used for gitlab pipeline.
Here are some examples of what I've tried so far:
- sudo cp /builds/project/openjdk-17_linux-x64_bin.tar.gz /usr/lib/jvm
- sudo tar zxvf "/usr/lib/jvm/openjdk-17_linux-x64_bin.tar.gz" -C /usr/lib/jvm
- echo "JAVA_HOME=/usr/lib/jvm/jdk-17" | sudo tee -a /etc/profile
- echo "PATH=${PATH}:${HOME}/bin:${JAVA_HOME}/bin" | sudo tee -a /etc/profile
- echo "export JAVA_HOME" | sudo tee -a /etc/profile
- echo "export JRE_HOME" | sudo tee -a /etc/profile
- echo "export PATH" | sudo tee -a /etc/profile
- sudo cat /etc/profile
- echo "JAVA_HOME=/usr/lib/jvm/jdk-17" | sudo tee -a /.bashrc
- echo "PATH=${PATH}:${JAVA_HOME}/bin" | sudo tee -a /.bashrc
- echo "JAVA_HOME='/usr/lib/jvm/jdk-17' | sudo tee -a /etc/environment"
- export JAVA_HOME=/usr/lib/jvm/jdk-17
- export PATH=$PATH:$JAVA_HOME/bin
After a lot of combinations of these commands the output of sudo update-alternatives --config java is still:
openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-post-Debian-2deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.12+7-post-Debian-2deb10u1, mixed mode, sharing)
But if I try /usr/lib/jvm/jdk-17/bin/java -version it prints 17.
What would be the solution of making the default Java version to be 17. (Also a solution for ant to use the JDK-17 without installing it would be great too, since I need the JDK-17 for ant)

Since you've already found a way to change the jdk on-the-go, you may really want to consider change the base image of your CI to save yourself a lot of time. This step will boost your CI speed. The steps to do that is fairly simple too.
Compose your own Dockerfile
This following is just a pesudo code. You may look into the description of dockerfile builder
FROM your-original-image. This is what you have in your image tag in the gitlab-ci file.
COPY jdk-17-linux-x64.tar.gz /usr/lib/jvm
RUN sudo tar zxvf "/usr/lib/jvm/jdk-17-linux-x64.tar.gz" -C /usr/lib/jvm \
&& sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/java-1.11.0-openjdk-amd64 \
&& sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/default-java \
&& sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/java-11-openjdk-amd64 \
&& sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/openjdk-11 \
&& sudo update-alternatives --remove-all java \
&& sudo update-alternatives --remove-all javac \
&& sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk-17/bin/java 1
Build the docker image
If you are using docker hub, then you need to login to docker and get a dockerId which matches the dockerId in the snippet.
If you are using a private repo like harbor or artifactory, you may need the permission to push to it.
docker build . -t dockerId/Name-of-your-image-you-want:latest
Upload the docker image using docker push
docker push dockerId/Name-of-your-image-you-want:latest
change the image tag in your gitlab-ci.yaml to dockerId/Name-of-your-image-you-want:latest

I found a solution.
- sudo cp jdk-17-linux-x64.tar.gz /usr/lib/jvm
- sudo tar zxvf "/usr/lib/jvm/jdk-17-linux-x64.tar.gz" -C /usr/lib/jvm
- sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/java-1.11.0-openjdk-amd64
- sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/default-java
- sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/java-11-openjdk-amd64
- sudo \cp -r /usr/lib/jvm/jdk-17 /usr/lib/jvm/openjdk-11
- sudo update-alternatives --remove-all java
- sudo update-alternatives --remove-all javac
- sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk-17/bin/java 1
What I did here was to copy the JDK-17 content to all folders from /usr/lib/jvm folder. So even though the docker image uses JDK-11, I'm rewriting it using JDK-17 uploaded with the source code, and now the tool is built using JKD-17.
PS: I know this is slower and not professional, but in my case, it's easier and more convinient than trying to get help from those who setup the docker container.

Unable to stop java process using SIGINT on Linux

I am building a virtual machine for some tests that needs to run among other things DynamoDb web service. VM is based on stock Ubuntu 16.04 64bit.
This is the part of provisioning script that installs DynamoDB:
# Install local instance of DynamoDB
DARCHFILE='/tmp/dynamodb_local_latest.zip'
wget -P /tmp/ -nv https://s3-us-west-2.amazonaws.com/dynamodb-local/dynamodb_local_latest.zip
sudo unzip -q "$DARCHFILE" -d /usr/local/lib/dynamodb
sudo mkdir -pv /var/lib/dynamodb/
sudo mkdir -pv /var/log/dynamodb/
sudo apt-get install -y openjdk-8-jdk
This is the script that executes DynamoDb:
#!/bin/bash
# -*- mode: sh -*-
# vi: set ft=sh :
java -Djava.library.path=/usr/local/lib/dynamodb/DynamoDBLocal_lib/ \
-jar /usr/local/lib/dynamodb/DynamoDBLocal.jar \
-dbPath /var/lib/dynamodb/ \
-optimizeDbBeforeStartup \
-port 8000 > /var/log/dynamodb/trace.log 2> /var/log/dynamodb/error.log &
echo $! > /var/run/dynamodb.pid
Now if I try to stop the process using the "nice one" SIGINT (equivalent of Ctrl+C) it does nothing. Only sending SIGTERM works.
So this does nothing:
sudo kill -s SIGINT $(< /var/run/dynamodb.pid)
As we can confirm by executing this:
sudo ps -x | grep $(< /var/run/dynamodb.pid)
While this works just fine:
sudo kill -s SIGTERM $(< /var/run/dynamodb.pid)
On the other hand if I start dynamodb manually and don't send it to the background Ctrl+C does work.
So what gives? Is it my mistake or behavior by design?
Thanks

Jenkins Java VM error when running a Maven test - Unrecognized VM option 'MaxPermSize-128m'

The problem is, we changed that from MaxPermSize-128m to MaxPermSize=128m
but the system keeps giving us that error:
We even restarted Jenkins.
Is it caching something, or there is more than one place where this setting should be changed?
[workspace] $ /usr/lib/jvm/java-6-openjdk-amd64/bin/java -Xmx512m -XX:MaxPermSize-128m -cp /mnt/www/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.3.jar:/mnt/www/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.1.0/boot/plexus-classworlds-2.4.2.jar org.jvnet.hudson.maven3.agent.Maven3Main /mnt/www/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.1.0 /var/cache/jenkins/war/WEB-INF/lib/remoting-2.28.jar /mnt/www/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.3.jar 55896
Unrecognized VM option 'MaxPermSize-128m'
Could not create the Java virtual machine.
ERROR: Failed to launch Maven. Exit code = 1
the output of 'ps -ef | grep java' is:
root 3509 1 0 Jul12 ? 00:07:17 /usr/local/share/elasticsearch/bin/service/exec/elasticsearch-linux-x86-64 /usr/local/share/elasticsearch/bin/service/elasticsearch.conf wrapper.syslog.ident=elasticsearch wrapper.pidfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.pid wrapper.name=elasticsearch wrapper.displayname=ElasticSearch wrapper.daemonize=TRUE wrapper.statusfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.status wrapper.java.statusfile=/usr/local/share/elasticsearch/bin/service/./elasticsearch.java.status wrapper.script.version=3.5.14
root 3511 3509 0 Jul12 ? 00:45:11 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java -Delasticsearch-service -Des.path.home=/usr/local/share/elasticsearch -Xss256k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -Djava.awt.headless=true -Xms1024m -Xmx1024m -Djava.library.path=/usr/local/share/elasticsearch/bin/service/lib -classpath /usr/local/share/elasticsearch/bin/service/lib/wrapper.jar:/usr/local/share/elasticsearch/lib/elasticsearch-0.19.11.jar:/usr/local/share/elasticsearch/lib/elasticsearch-0.19.11.jar:/usr/local/share/elasticsearch/lib/jna-3.3.0.jar:/usr/local/share/elasticsearch/lib/log4j-1.2.17.jar:/usr/local/share/elasticsearch/lib/lucene-analyzers-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-core-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-highlighter-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-memory-3.6.1.jar:/usr/local/share/elasticsearch/lib/lucene-queries-3.6.1.jar:/usr/local/share/elasticsearch/lib/snappy-java-1.0.4.1.jar:/usr/local/share/elasticsearch/lib/sigar/sigar-1.6.4.jar -Dwrapper.key=b1QUXxfrVfakmb6w -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.disable_console_input=TRUE -Dwrapper.pid=3509 -Dwrapper.version=3.5.14 -Dwrapper.native_library=wrapper -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp org.elasticsearch.bootstrap.ElasticSearchF
jenkins 20372 1 0 08:17 ? 00:00:00 /usr/bin/daemon --name=jenkins --inherit --env=JENKINS_HOME=/mnt/www/jenkins --output=/var/log/jenkins/jenkins.log --pidfile=/var/run/jenkins/jenkins.pid -- /usr/bin/java -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
jenkins 20373 20372 23 13:20 ? 00:05:51 /usr/bin/java -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1
root 29403 28220 0 13:45 pts/0 00:00:00 grep --color=auto java

How did you expect to set the maximum to a negative value? I think you wanted
-XX:MaxPermSize=128m
-- Update ---
Ok, so you have fixed this, but the build still fails.
Look into the "workspace cleanup plugin", and if it is not installed, install it and activate it. The workspace cleanup plugin will remove evidence of prior builds from the workspace before launch. Odds are that the configuration is stored to file, and then referenced from file immediately prior to launch.
You could move into the workspace directories and grep for the "minus 128" version of the command and alter it by hand, but by using the plugin you also avoid future similar issues.