Not much detail here, but throwing out a couple guesses... 1.) Is the dependent app crashing (might account for a 2 - 3 minute unavailability depending on how slowly the app restarts)? You might try a

wrote: It depends. It will download from CC / Blob Store for build packs listed in `cf buildpacks`. If a developer points to a Git repository, then it will pull the build pack from that repository. Gi

Look at the access log for Nginx. It's up a directory, `nginx_cc/access.log` (I think). Make sure that you see the request listed in the access log. The access log contains all incoming requests so if

Did you recently `bosh recreate`, `bosh deploy` or has the resurrector recently recreated the VM (maybe check the uptime if you're unsure)? These are all things that can cause the VM to be rebuilt and

That would be the file. It should have more details. You can try searching on the vcap-request-id or you can look at the access log that nginx writes, look for the request to /v2/organizations that's

Look at your cloud controller logs. You should see some reason for the 500 error. That should give you more clues as to why it's failing. Dan

Prematurely sent that, meant to include this link: https://github.com/cloudfoundry/diego-ssh#cloud-foundry-via-cloud-controller-and-uaa Dan

Can you expand on this? What exactly are you trying to do? Delete the log files written by the app? Download log files written by the app for review? something else? Do you have Diego? If so, `cf ssh`

Not sure about if / how you'd do this with gorouter. However you'll end up with a load balancer in front of your gorouters, so I suppose you could always have the load balancer remove headers from the

That step is setting up Postgres to run as a service. I think the Ubuntu equivalent would be upstart or systemd. You probably don't need to do this on Ubuntu as the postgres package should come with a

Here's what worked for me: manifest.yml ``` --- applications: - name: jmeter-test memory: 512M instances: 1 path: . buildpack: java_buildpack command: 'JAVA_HOME=.java-buildpack/open_jdk_jre PATH=$PAT

daniel.jones(a)engineerbetter.com> wrote: +1 Why not? What happens when you try this? What fails. Have you tried manually setting a command? You can set the `-c` arg to `cf push` and it should run the

By "here", I meant under "resources/tomcat/conf" in your fork.

Sorry, email prematurely sent. With the JBP you have two options: 1.) Fork the JBP and make your config changes here: https://github.com/cloudfoundry/java-buildpack/tree/master/resources/tomcat/conf 2

With the JBP you have two options: 1.) Fork the JBP and make your config changes here: 2.)

Can you use a `.profile.d` script? You can set environment variables in that and they'll be accessible by your app. Dan

MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote: I don't believe that you should use `/tmp`. Look at your env variables, I recall there being a $TMPDIR that you can use for temporary files. Probab

I don't think this is related to PWS. In this case UAA is just another app running on CF, so it's really an issue about how UAA is loading it's database configuration. From the instructions here [1],

wrote: Do you have logs from UAA? The UAA logs will sometimes tell you more about the response you received. Dan

Need more info. What's the command(s) you're running? What's the full output from the command(s)? What is the output of `cf target`? Is Diego supported / available on that target? Dan