Thanks for the additional information. With the app in a started state, if
you run `cf logs my-app` and wait, do you see that CF eventually restarts
the lattice-app instance without your manual intervention? Does it then
crash again after a short period of time? Does that occur for other apps
you push to the Diego backend, either Docker-image-based or
buildpack-based? The `cloudfoundry/diego-docker-app` image is another
Docker image that the CF Acceptance Test suite pushes as a CF app, which
you could try running via `cf push dda -o cloudfoundry/diego-docker-app`. I
would be interested to know if it exhibits the same behavior.
It would be interesting to see the rep and garden logs from the Diego cell
that's running the instance. You should be able to find logs for the
instance by searching in /var/vcap/sys/log/rep/rep.stdout.log for the app
guid for that app (which you can find by running `cf app --guid my-app`),
but if you have many cells in the deployment this process can be tedious.
Since the app does run for some period of time, when it is running you can
also find the IP address of the Diego cell from CC's app stats endpoint.
Run `cf curl /v2/apps/$(cf app --guid my-app)/stats` and look for the IP
address in the 'host' field in the response. From there, you can use BOSH
to locate the cell it's running on and retrieve or inspect those logs.
Best,
Eric
toggle quoted message
Show quoted text
On Sun, Jun 12, 2016 at 1:20 AM, 王小锋 <zzuwxf(a)gmail.com> wrote: Hi, Eric
Thanks for your response.
garden-linux is 0.337.0, and the other releases are as follows:
+-------------------+-----------+-------------+
| Name | Versions | Commit Hash |
+-------------------+-----------+-------------+
| cf | 210 | 211e35ec+ |
| | 212 | ae2ec7a5+ |
| | 218 | a80b4f5b+ |
| | 233 | 11e3eaec+ |
| | 237* | 87f11091+ |
| cflinuxfs2-rootfs | 1.14.0* | 859a06a0+ |
| diego | 0.1472.0* | 150b4295 |
| etcd | 51* | 5af0b786 |
| garden-linux | 0.337.0* | a7d9ddac |
+-------------------+-----------+-------------+
When I restart the application, it will keep "running" for a second, then
go to "down" status, cf restart my-app shows:
ubuntu(a)ip-10-10-0-118:~$ cf restart my-app
Stopping app my-app in org org-devtest / space test as admin...
OK
Starting app my-app in org org-devtest / space test as admin...
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
1 of 1 instances running
App started
OK
App my-app was started using this command `/lattice-app `
Showing health and status for app my-app in org org-devtest / space test
as admin...
OK
requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: my-app.example.com
last uploaded: Sun Jun 12 05:44:14 UTC 2016
stack: cflinuxfs2
buildpack: unknown
state since cpu memory disk
details
#0 running 2016-06-12 08:16:35 AM 0.0% 0 of 1G 0 of 1G
2016-06-12 15:53 GMT+08:00 Eric Malm <emalm(a)pivotal.io>:
Hi,
Does the lattice app instance stay in a down state? What happens when CF
restarts it? Also, what version of garden-linux-release is deployed?
I've just now been able to run `cf push lattice-app -o
cloudfoundry/lattice-app` to push the lattice-app image to a CF environment
running dev versions of CF and Diego later than v237 and v0.1472.0,
respectively, and according to the logs it runs fine. I observe the pair of
exit-status codes you report from the logs of this instance only when I
intentionally stop the entire app or use `cf restart-app-instance` to
restart one of its instances.
Thanks,
Eric, CF Runtime Diego PM
On Sat, Jun 11, 2016 at 11:44 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:
Hi, there
I uploaded my cf deployment from 233 to 237 using bosh, and deploy
diego(diego-release-0.1472.0) along cf deployoment.
The deployment itself is successful. And I am able to push apps using
buildpacks to diego backend instead of DEA backend.
Howerver, when I try to push docker image to diego backend using
command:
*cf docker-push my-app cloudfoundry/lattice-app*
It failed to start , cf app my-app shows the status is down:
cf app my-app
requested state: started
instances: 0/1
usage: 1G x 1 instances
urls: my-app.example.com
last uploaded: Sun Jun 12 05:44:14 UTC 2016
stack: cflinuxfs2
buildpack: unknown
state since cpu memory disk
details
#0 *down* 1970-01-01 12:00:00 AM 0.0% 0 of 1G 0 of 1G
cf docker-push my-app cloudfoundry/lattice-app
and cf logs my-app--recent shows "Lattice-app" starts successfully
first, then exit with some error. Any suggestions? Your help is appreciated!
016-06-12T05:44:14.76+0000 [API/0] OUT Created app with guid
c6c68c6b-7727-45ba-a5e9-d7a7867cc5e4
2016-06-12T05:44:15.04+0000 [API/0] OUT Updated app with guid
c6c68c6b-7727-45ba-a5e9-d7a7867cc5e4
({"route"=>"c34726a5-1275-47a4-9a49-b7a481753200"})
2016-06-12T05:44:15.68+0000 [API/0] OUT Updated app with guid
c6c68c6b-7727-45ba-a5e9-d7a7867cc5e4 ({"state"=>"STARTED"})
2016-06-12T05:44:33.95+0000 [STG/0] OUT Creating container
2016-06-12T05:44:34.19+0000 [STG/0] OUT Successfully created
container
2016-06-12T05:44:34.19+0000 [STG/0] OUT Staging...
2016-06-12T05:44:34.21+0000 [STG/0] OUT Staging process started ...
2016-06-12T05:44:36.28+0000 [STG/0] OUT Staging process finished
2016-06-12T05:44:36.28+0000 [STG/0] OUT Exit status 0
2016-06-12T05:44:36.28+0000 [STG/0] OUT Staging Complete
2016-06-12T05:44:36.52+0000 [CELL/0] OUT Creating container
2016-06-12T05:44:48.13+0000 [CELL/0] OUT Successfully created
container
2016-06-12T05:44:48.13+0000 [CELL/0] OUT Starting health monitoring
of container
2016-06-12T05:44:48.15+0000 [APP/0] OUT
{"timestamp":"1465710288.151398897","source":"lattice-app","message":"lattice-app.lattice-app.starting","log_level":1,"data":{"ports":["8080"]}}
2016-06-12T05:44:48.15+0000 [APP/0] OUT
{"timestamp":"1465710288.151749372","source":"lattice-app","message":"lattice-app.lattice-app.up","log_level":1,"data":{"port":"8080"}}
2016-06-12T05:44:48.65+0000 [CELL/0] OUT Container became healthy
2016-06-12T05:44:49.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:50.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:51.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:52.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:53.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:54.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:55.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:56.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:57.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:58.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:44:59.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:00.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:01.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:02.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:03.15+0000 [APP/0] OUT Lattice-app. Says Hello. on
index: 0
2016-06-12T05:45:04.09+0000 [CELL/0] OUT Exit status 0
2016-06-12T05:45:04.09+0000 [APP/0] OUT Exit status 2
|
