Date
1 - 8 of 8
Facing problem while pushing Spring Boot app on PCF
|
Mohan V <mohan221213@...>
I am trying to push the simple spring boot app in pcf.
I am completely new to pcf. I was created manifest.yml file which contain following data:- applications: - name: PivotalPushTest host: PivotalPushTest memory: 512M instances: 1 path: /root/Desktop/PivotalPushTest/target/PivotalPustTest-0.0.1-SNAPSHOT.jar but when I am pushing this app via cf push command I am getting following error:- cf push Using manifest file /root/Desktop/PivotalPushTest/manifest.yml Creating app PivotalPushTest in org ORGNAME / space Java-Hadoop as username(a)domainname.com... OK Using route PivotalPushTest.url.com Binding PivotalPushTest.url.com to PivotalPushTest... OK Uploading PivotalPushTest... Uploading app files from: /tmp/unzipped-app911037164 Uploading 6.1K, 16 files Done uploading OK Starting app PivotalPushTest in org ORGNAME / space Java-Hadoop as username(a)domainname.com... Downloading python_buildpack... Downloading php_buildpack... Downloading java_buildpack_offline... Downloading null_buildpack... Downloading go_buildpack_1-6... Downloading staticfile_buildpack... Downloading binary_buildpack... Downloading ruby_buildpack... Downloading nodejs_buildpack... Downloading go_buildpack... Downloaded python_buildpack Downloaded nodejs_buildpack Downloaded binary_buildpack Downloaded php_buildpack Downloaded go_buildpack Downloaded go_buildpack_1-6 Downloaded ruby_buildpack Downloaded java_buildpack_offline Downloaded null_buildpack Downloaded staticfile_buildpack Creating container Successfully created container Downloading app package... Downloaded app package (6.6K) Staging... -----> Nothing to do. **No start command detected; command must be provided at runtime** Exit status 0 Staging complete Uploading droplet, build artifacts cache... Uploading droplet... Uploading build artifacts cache... Uploaded build artifacts cache (109B) Uploaded droplet (3.7K) Uploading complete 0 of 1 instances running, 1 crashed FAILED Error restarting application: Start unsuccessful TIP: use 'cf logs PivotalPushTest --recent' for more information In Apps Manager Logs:- OUT Exit status 1 2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage: /tmp/lifecycle/launcher <app directory> <start command> <metadata>** 2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2 2016-09-28T07:05:58.000+00:00 [API] OUT App instance exited with guid 637a95a7-4def-4c43-b00e-454ca6f584f8 payload: {"instance"=>"460e1817-d616-495e-407e-49991b0026b0", "index"=>0, "reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2 error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled", "crash_count"=>1, "crash_timestamp"=>1475046358426721004, "version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"} 2016-09-28T07:05:58.000+00:00 [CELL] OUT Creating container 2016-09-28T07:05:58.000+00:00 [CELL] OUT Successfully created container 2016-09-28T07:05:58.000+00:00 [CELL] OUT Starting health monitoring of container 2016-09-28T07:05:58.000+00:00 [APP] OUT Exit status 1 2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage: /tmp/lifecycle/launcher <app directory> <start command> <metadata>** 2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2 2016-09-28T07:05:59.000+00:00 [API] OUT App instance exited with guid 637a95a7-4def-4c43-b00e-454ca6f584f8 payload: {"instance"=>"06f0d873-0050-4e66-6bc8-11ec83ec369f", "index"=>0, "reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2 error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled", "crash_count"=>2, "crash_timestamp"=>1475046358988785723, "version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"} 2016-09-28T07:05:59.000+00:00 [CELL] OUT Creating container 2016-09-28T07:05:59.000+00:00 [CELL] OUT Successfully created container 2016-09-28T07:05:59.000+00:00 [CELL] OUT Starting health monitoring of container 2016-09-28T07:05:59.000+00:00 [APP] OUT Exit status 1 2016-09-28T07:05:59.000+00:00 [APP] ERR Usage: /tmp/lifecycle/launcher <app directory> <start command> <metadata> 2016-09-28T07:05:59.000+00:00 [CELL] OUT Exit status 2 Please Help, Mohan V. |
|
|
|
Daniel Mikusa
What is the system you are targeting? For example, a bosh lite install,
PCF-dev, PWS, Bluemix, other? If it's a system you deployed, which CF Release & Diego release are you using? Also, can you push *any* applications to it successfully? Maybe try a few samples from here [1] and see if any of them work. 2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage: /tmp/lifecycle/launcher<app directory> <start command> <metadata>** It's this output that has me concerned. You might also want to check the cell logs to see if there's any additional output on why the launcher is failing or what arguments it's being given (that it clearly doesn't like). Dan [1] - https://github.com/cloudfoundry-samples/ On Wed, Sep 28, 2016 at 3:44 AM, Mohan V <mohan221213(a)gmail.com> wrote: I am trying to push the simple spring boot app in pcf. |
|
|
|
John Liptak
I would also specify the java buildpack. If there is a structural problem
toggle quoted message
Show quoted text
in your jar file, the java buildpack may not be detecting it as a Java application and some other buildpack is attempting to package it. Generally, spring boot applications and Java buildpacks should have a start command. John On Wed, Sep 28, 2016 at 6:09 AM Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
What is the system you are targeting? For example, a bosh lite install, |
|
|
|
Daniel Mikusa
Disregard what I said earlier. I think John's right. The output from
staging is showing... Staging...That looks like it could be coming from the null-buildpack. https://github.com/ryandotsmith/null-buildpack/blob/master/bin/compile So try specifying `-b java_buildpack_offline` to `cf push` or `buildpack: java_buildpack_offline` in your manifest.yml. That will force it to use the JBP. Then see what happens. Like John said, there might be something off with the JAR file that you also need to fix. Dan On Wed, Sep 28, 2016 at 10:01 AM, John Liptak <john.h.liptak(a)gmail.com> wrote: I would also specify the java buildpack. If there is a structural problem |
|
|
|
Mike Dalessio
There's still something weird going on ...
toggle quoted message
Show quoted text
We know that buildpack detection is happening, because we see all the buildpacks being fetched by Diego in the log. But the null buildpack should never be detected: https://github.com/ryandotsmith/null-buildpack/blob/master/bin/detect Also, it would mean the null buildpack was set as an admin buildpack (which it wouldn't be by default on PCF) ... it sounds like this CF installation has been mucked around with from the sane default configuration. On Wed, Sep 28, 2016 at 10:33 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
Disregard what I said earlier. I think John's right. The output from |
|
|
|
John Feminella <jxf@...>
But the null buildpack should never be detected:My reading of this is "the null buildpack is *always* detected". I thought a buildpack was detected if it returns 0: https://docs.cloudfoundry.org/buildpacks/custom.html#detect-script On Wed, Sep 28, 2016, 10:50 Mike Dalessio <mdalessio(a)pivotal.io> wrote: There's still something weird going on ... |
|
|
|
Mike Dalessio
Ah, you're absolutely right -- my mistake. That makes sense, then.
toggle quoted message
Show quoted text
On Fri, Sep 30, 2016 at 4:16 AM, John Feminella <jxf(a)pivotal.io> wrote:
But the null buildpack should never be detected:My reading of this is "the null buildpack is *always* detected". I thought |
|
|
|
Mike Dalessio
Worth noting that we recommend using cloudfoundry/binary-buildpack in place
of the community null-buildpack. The `binary-buildpack` is supported by the core OSS team, and does not suffer from this always-detect behavior. On Fri, Sep 30, 2016 at 10:25 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: Ah, you're absolutely right -- my mistake. That makes sense, then. |
|
|