Could we please, please not call it `cflinuxfs3`? A very common question I get is what is `cflinuxfs2` really? I then have to explain that it is basically Ubuntu Trusty. That invariably results in the

Try running `jcmd <pid> VM.native_memory summary` to get a full summary of the memory being used by the JVM. Looks like this. ``` $ jcmd 72082 VM.native_memory summary 72082: Native Memory Tracking: T

Start running `cf logs` in a second terminal. The log output should show more details about what is happening while the app is starting. Hopefully that will show what is taking up the time. Dan

I believe that is the expected behavior. See the last bullet point here. https://docs.cloudfoundry.org/concepts/docker.html#caveats Dan

Don't be led astray here. With the DEA when an app crashes, you will pretty much always be told "failed to accept connection within health check timeout" (Diego is better and gives more helpful error

The problem is that your app is crashing. Fortunately the reason in this case is clear from the exit status. 127 means "command not found". This is a convention in Linux. http://tldp.org/LDP/abs/html/

You don't have root access in application containers. You could bundle the software into a custom build pack. Again, you can't install stuff with root so you have to manually extract the files somewhe

Correct. There's a couple ways you can create the target app. Push a dummy app or use the API directly (i.e. `cf curl` [1]). Once you create the target app, copy source will override whatever is in th

Have you looked at `cf copy-source`? You can use that to copy one app to another. You could then change service bindings, environment variables and scale the copy of the app separately. I believe you

wrote: The time stamp on the request and response are exactly 60 seconds apart. Do you have any timeouts that are set to 60 seconds? Perhaps on your load balancer? Dan

I know some of the build packs will look at application name and use that for configuration of some of the APM agents (NewRelic, AppDynamics, etc..). Ex: https://github.com/cloudfoundry/java-buildpack

If possible add more logging or increase logging levels. Not sure what language / runtime you're using, but you might be able to add an exit hook or some code that is guaranteed to run before your app

This isn't really a problem with the build pack. It's a problem with compiling one of the native modules that you are using ` dtrace-provider(a)0.2.8`. Not sure why that's failing. There's some info i

It is the exit status of your application. In other words, your app exited and returned this number. http://tldp.org/LDP/abs/html/exit-status.html It may be an application specific number or it could

wrote: How is this comment related to this email thread or helpful? Dan

Are you sure the request is actually making it to your app? Requests that come into CF go through a load balancer and the gorouters before they hit your app. ie. browser -> your LB -> gorouters -> app

It's the cf cli that does this. It looks through your JAR / WAR or push path for files and then uses the resource matching endpoint to ask the server what it needs to upload. Then it uploads just thos

Does the app actually push and get started? i.e. if you run `cf apps` after you get this message is the app up and running? Also, do you see similar issues when you push with `cf push`? Take a look at

As an experiment, I created a build pack that would do this. It hasn't been updated in a while, I don't plan to update it and it was never very solid to begin with. It was more to just see if I could

wrote: There's two parts to this problem: 1.) You need to get metrics from the platform. I don't think (although this could have changed, since it's being rewritten at the moment) that cf-java-client