I am using cf for the first time, trying to deploy a simple app to Bluemix. When I try cf push, I get this error:
E:\Program Files\tomcat\apache-tomcat-8.0.41\webapps\helloServletMaven\target
λ cf push /helloServletMaven -p /helloServletMaven.war
Creating app /helloServletMaven in org alexander.kirwan / space ORG as alexander.kirwan#mycit.ie...
OK
Using route helloservletmaven.mybluemix.net
Binding helloservletmaven.mybluemix.net to /helloServletMaven...
OK
FAILED
Error processing app files: GetFileAttributesEx E:\helloServletMaven.war: The system cannot find the file specified.
E:\Program Files\tomcat\apache-tomcat-8.0.41\webapps\helloServletMaven\target
λ ls
classes/ generated-sources/ helloServletMaven/ helloServletMaven.war m2e-wtp/ maven-archiver/ maven-status/ test-classes/
E:\Program Files\tomcat\apache-tomcat-8.0.41\webapps\helloServletMaven\target
But as you can see, when I run ls, I do have the war file.
Why is this happening?
By the way, I am using Windows and CMDER for the console.
It looks like your file is in the local directory so you don't have use /helloServletMaven.war, i.e. remove the slash (/)
cf push helloServletMaven -p helloServletMaven.war
Related
I am trying to use a tool that, in two steps, analyzes code smells for android.
In the first step, the tool parses an apk and generates within a directory .db files that should then be converted to CSV files in the next step; however, whenever I try to run the second step, the console returns the following error:
java.io.IOException: Unable to create directory path [/User/Desktop/db2/logs] for Neo4j store.
I think it is a Neo4J configuration problem.
I am currently running the tool with the following Java configuration:
echo $JAVA_HOME
/home/User/openlogic-openjdk-11.0.15
update-alternatives --config java
* 0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 auto mode
To be safe, I also started Neo4J, which returned the following output
sudo systemctl status neo4j.service
neo4j.service - Neo4j Graph Database
Loaded: loaded (/lib/systemd/system/neo4j.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-07-06 20:11:04 CEST; 16min ago
Main PID: 1040 (java)
Tasks: 57 (limit: 18901)
Memory: 705.4M
CPU: 16.639s
CGroup: /system.slice/neo4j.service
└─1040 /usr/bin/java -cp "/var/lib/neo4j/plugins:/etc/neo4j:/usr/share/neo4j/lib/*:/var/lib/neo4j/plugins/*" -XX:+UseG1GC -XX:-OmitStackTraceInFastThrow -XX:+AlwaysPreTouch -XX:+UnlockExper>.
How can I solve this?
You posted this error:
java.io.IOException: Unable to create directory path [/User/Desktop/db2/logs] for Neo4j store.
From that error, it looks like:
Neo4j was installed at "/User/Desktop/db2"
The permissions for that directory do not have "write" permission
I tried to reproduce this locally using Neo4j Community 4.4.5, following the steps below.
I do see an IOException related to "logs", but it's slightly different from what you posted. Perhaps we're on different versions of Neo4j.
Open terminal into install directory: cd neo4j
Verify "neo4j" is stopped: ./bin/neo4j stop
Rename existing "logs" directory: mv logs logs.save
Remove write permission for the Neo4j install: chmod u-w .
Start neo4j in console mode: ./bin/neo4j console
Observe errors in console output
2022-07-08 03:28:38.081+0000 INFO Starting...
ERROR StatusLogger Unable to create file [****************************]/neo4j/logs/debug.log
java.io.IOException: Could not create directory [****************************]/neo4j/logs
...
To fix things, try:
Get a terminal into your Neo4j directory:
cd /User/Desktop/db2
Set write permissions for the entire directory tree:
chmod u+w -R .
Start neo4j in console mode:
./bin/neo4j console
If this works and you're able to run neo4j fine, it points to an issue with user permissions when running neo4j as a system service.
The best steps from there depend on the system, your access, how comfortable you are making changes, probably other things. An easy, brute-force hammer would be to manually create each directory you discover (such as "/User/Desktop/db2/logs") and grant premissions to all users (chmod ugo+w .), then try re-running the service, see what errors pop up. Repeat that until you're able to run the service without errors.
Trying to deploy a Play Framework based Application using an ELB container
Recently it seems that AWS made changes to the way ELB works as we've done this before without issue.
The error we currently get is:
2021/12/14 23:00:15.705423 [INFO] Executing instruction: CheckProcfileForJavaApplication
2021/12/14 23:00:15.705468 [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForJavaApplication]. Stop running the command. Error: there is no Procfile and no .jar file at root level of your source bundle
2021/12/14 23:00:15.705474 [INFO] Executing cleanup logic
2021/12/14 23:00:15.705598 [INFO] CommandService Response: {"status":"FAILURE","api_version":"1.0","results":[{"status":"FAILURE","msg":"Engine execution has encountered an error.","returncode":1,"events":[{"msg":"Instance deployment failed. For details, see 'eb-engine.log'.","timestamp":1639522815,"severity":"ERROR"}]}]}
Now of course I wouldn't be here if this was the actual problem
# cd /var/app/staging/server-xxxxxxxxxxx/
# ls -l
total 16
-rw-r--r-- 1 webapp webapp 135 Dec 14 20:39 Procfile
drwxr-xr-x 2 webapp webapp 82 Dec 14 22:21 bin
drwxr-xr-x 2 webapp webapp 113 Dec 14 22:21 conf
drwxr-xr-x 2 webapp webapp 8192 Dec 14 22:21 lib
drwxr-xr-x 3 webapp webapp 17 Dec 14 22:21 share
So Procfile exists
Hmmm is it valid however?
Let's check that out:
# cat Procfile
web: bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dhttp.port=5000 -Dhttps.port=8443 -Dconfig.resource=application.conf
Looks normal enough -- but does it actually work?
Short answer is yes -- if I copy and paste that command (minus the "web:" prefix of course) system comes up without any issues (ELB still fails to realize that though...)
I've tried a few variants of the command thinking that it might be related to yaml formatting of perhaps a tighter regex ^[A-Za-z0-9_-]+:\s*[^\s].*$ (source: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html)
web: bin/server
web: ./bin/server
web: bin/server
web: ./bin/server
web:bin/server
web:./bin/server
No difference (both worked when manually started without or without the leading ./ btw)
Unsure how I move forward here?
How do we find what the real problem is so that we have fighting chance to fix it?
And yes -- the initial trace above is already the output of eb-engine.log
Using (in case this is relevant)
Coretto Java 11
Play 2.8.8
Scala 2.13.6
SBT 1.5.2
Will answer any relevant queries that help improve this question and any chance of resolving it. Most Google searches I've dug through are related to other environments and are simply a missing Procfile...
I have worked out the following work-around to be able to use a standard (well slightly modified) Play Framework dist directly in an AWS ELB Java container
We start with the typical sbt dist process to create a zip "distribution" file
That file won't work in the format it is currently in (I've been researching and I will be asking specific questions to see if making it work directly might be possible) however it only takes a few small tweaks to get it to work
First Step: Modify Procfile (a file that you manually create and place in the project's dist directory) as follows:
web: chmod 700 bin/server; bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dpidfile.path=/dev/null -Dhttp.port=5000 -Dconfig.resource=application.conf
Note the chmod 700 bin/server; that was the final secret sauce required to make this work! I was kinda shocked that it did work actually. I did not think that would get past the regex they use to parse the Procfile
As a zip file is permissions agnostic, once I finally got the elb install process to get past that first "missing jar" hurdle I noticed the permissions on bin/server were simply rw. The ec2 instance's /var/log/eb-engine.log did not quite spell that out too clearly, however I confirmed that whenever I manually modified those permissions (on the ec2 instance) and then ran the bin/server command (to verify it) the Play server would start right away (however the elb container still failed to see it as a legitimate process and continued to report it as Status of no data, nor did it allow the load balancer to send it traffic so this "fix" was a real shot in the dark!)
Second step: Unzip that zip file and cd into the directory it created/assigned
cd server-vxxxxxxxxxxxxxx
touch placeholder.jar
The second dab of secret sauce is that the placeholder.jar file is simply a means to satisfy the CheckProcfileForJavaApplication which simply looks for the existence of any file named *.jar in the root of the bundled directory. If that file does not exist then the elb install script stops dead in it's tracks.
Note: You could simply place this empty placeholder.jar file in the Play dist folder if you prefer
Third Step: Create a new zip file elb.zip
zip --exclude share/doc/api/\* -r elb.zip .
Now take elb.zip and upload it to an AWS ELB container and low and behold it (finally) springs to life!
I want to copy file to the not running container via Docker Client by Spotify -
File is created like -
File.createTempFile("olb-", "-temp").deleteOnExit().writeText("some text")
When I try:
client.copyToContainer(inputFileProvider.createFile(task.dataToInsert).toPath(), containerId, "/app/asd.json")
I get:
Either container 1adbf9c1ee511272bec78a46be08bf9299c317b11cdb176eed986640ac86a38c or path /app/my_json.json not found.
Well, ok - I create this file while building image with RUN touch /app/my_json.json
Next run:
client.copyToContainer(inputFileProvider.createFile(task.dataToInsert).toPath(), containerId, "/app/my_json.json")
Resulted in
{"message":"extraction point is not a directory"}
Ok... I tried directory
copyToContainer(inputFileProvider.createFile(task.dataToInsert).toPath(), containerId, "/app/")
Result:
{"message":"Error processing tar file(exit status 1): cannot overwrite directory \"/\" with non-directory \"/\""}
Same for "/app"
Any ideas how to copy file into docker container via Java client?
It turned out that I must create whole new folder, then single file in it and copy that folder.
val dir = Files.createTempDirectory("tem-folder-")
Files.createFile(dir.resolve("filename")).toFile().writeText("data to write")
val toBeCopied = dir.toFile()
cliend.copyToContainer(toBeCopied.toPath(), "containerId", "targetPath")
Steps:
create new project with start.spring.io
run it localy - works
run gradle task jar
push jar to bluemix cf push demoWar.jar
Downloaded app package (20.1M) Staging... None of the buildpacks
detected a compatible application Exit status 222 Staging failed:
Exited with status 222 Destroying container
FAILED Error restarting application: NoAppDetectedError
TIP: Buildpacks are detected when the "cf push" is executed from
within the dire ctory that contains the app source code.
Try two things:
1. Use the -p command to target your deployable artifact. This would look something like cf p APP_NAME -p PATH_TO_YOUR_WAR. I usually chain my build and deploy commands so: mvn clean package && cf p APP_NAME -p PATH_TO_YOUR_WAR.
If this doesn't work then you can specify a build pack. So cf p APP_NAME -p PATH_TO_YOUR_WAR -b SOME_BUILDPACK. You can see the available build packs by calling cf buildpacks.
Hope this helps.
When deploying first time your app on cloud foundry then following command will not work
cf push TestService
you need to use following command
cf push -p TestService-0.0.1-SNAPSHOT.jar testService
Useful link :
https://discuss.pivotal.io/hc/en-us/articles/226273647-Troubleshooting-error-None-of-the-buildpacks-detected-a-compatible-application-exit-status-222-
https://docs.cloudfoundry.org/buildpacks/detection.html
Else add manifest.yml on root
applications:
- name: Demo
memory: 2G
disk_quota: 2G
instances: 1
path: target/demo-local-0.0.1-SNAPSHOT.jar
env:
SPRING_PROFILES_ACTIVE : "dev"
routes:
- route: demo.app.dev.vk.vaquar.khan.com
after that go to path and run cf push < JAR_NAME>
I'm trying to run Jetty on CentOS and am having problems as I am getting unexpected results when I try to set the full path for JETTY_LOGS. The system tries to take that path and append it to the path I specified in the JETTY_HOME variable.
JETTY_HOME=/usr/local/jetty/jetty-9.1.4
JETTY_USER=jetty
JETTY_PORT=8085
JETTY_HOST=0.0.0.0
JETTY_LOGS=/usr/local/jetty/jetty-9.1.4/logs
Any ideas as to what I'm doing wrong?
The error I get is:
Starting Jetty: java.io.IOException: Cannot write start.log to directory
/usr/local/jetty/jetty-9.1.4/usr/local/jetty/jetty-9.1.4/logs [directory doesn't exist or is read-only]
java.io.IOException: Cannot write start.log to directory /usr/local/jetty/jetty-9.1.4/usr/local/jetty/jetty-9.1.4/logs [directory doesn't exist or is read-only]
at org.eclipse.jetty.start.StartLog.initLogFile(StartLog.java:127)
at org.eclipse.jetty.start.StartLog.initialize(StartLog.java:113)
at org.eclipse.jetty.start.Main.processCommandLine(Main.java:520)
at org.eclipse.jetty.start.Main.main(Main.java:102)
It seems that JETTY_LOG directory is relative to JETTY_HOME.
Could you try to set:
JETTY_LOGS=/logs
or alternatively
JETTY_HOME=/usr/local/jetty/jetty-9.1.4/
JETTY_LOGS=logs
You're not doing anything wrong, this is new behavior in jetty 9.1.4:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=432192
Workaround is to set the JETTY_LOGS env var relative to your jetty base dir (like the logs dir that comes in the standard jetty tarball):
JETTY_LOGS=logs
Which will resolve to /usr/local/jetty/jetty-9.1.4/logs in your case (the jetty base dir defaults to the jetty home dir).
If you want the logs written somewhere outside of your jetty base dir, the best way is to use the above JETTY_LOGS=logs env setting, and just symlink the dir elsewhere; like this to create and link to the common /var/log/jetty dir:
# mv /usr/local/jetty/jetty-9.1.4/logs /var/log/jetty
# ln -s /var/log/jetty /usr/local/jetty/jetty-9.1.4/logs
Whatever you do, also make sure that the user as which you run jetty has write access to the logs dir; if you use the jetty user in the jetty group, make it the owner of your logs dir:
# chown -R jetty:jetty /var/log/jetty