1. Messages
  2. CR Push failure

Re: CR Push failure

Dan Wendorf
 

Hi shahc,

Dan's answer covers most of the details. Cloud Foundry applications are
intended to be long-lived (endless until you explicitly stop them)
processes that respond to web requests. The health-check is attempting to
confirm this by connecting to the application via the HTTP port provided to
the application by the PORT variable.

Because you've set your start command to a non-web command (a MySQL task),
it will not respond on that port and Cloud Foundry considers that to be a
failure. If you want to perform one-off tasks during app start (e.g.
seeding your database), that's best done as part of your application's
startup process. A common pattern in pseudo-code is something like:

```
class MyApplicationBootstrap {
function start() {
if (migrationsNeeded()) {
runMigrations();
}

MyApplication.new().start();
}
}
```

There will be support for one-off tasks (what you are attempting to do) in
the near-future (see the current documentation for tasks
<http://v3-apidocs.cloudfoundry.org/version/release-candidate/index.html#tasks>
in
the experimental V3 API — note that it is subject to change and not yet
stable), but until then, the in-app startup bootstrap is the best solution.

Additionally, take care to not copy-paste credentials when posting in a
public forum. I recommend cycling the credentials for your service as soon
as possible.


Hope this helps,
(the other) Dan

On Mon, May 9, 2016 at 4:56 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Mon, May 9, 2016 at 2:41 AM, Stanley Shen <meteorping(a)gmail.com> wrote:

From the message "failed to accept connections within health check
timeout"
You can try to disable health check and have another try to see if it
works

cf set-health-check APP_NAME 'none'
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 messages). The DEA
isn't necessarily wrong, since the app in question isn't running and
listening for connections. It just lacks any sort helpful details about
why the app isn't running and listening for connections.

Possible causes:

- app not listening on the assigned port (i.e. $PORT)
- app has exited / crashes for some reason (look at exit_code in crash
message and application logs for clues)
- app is starting too slow (look at timestamp from DEA for `Starting
app instance` and subtract it from timestamp from DEA for crash message, if
the difference is right around the timeout then this is the problem)

Also, when you hit the start up timeout, you should *not* disable the
health check. You should first look to see why your application is taking
so long to start, especially if you're not expecting it to take a long time
to start. Check the application logs and see what it's doing. Three
common problems are when an app is having connection problems to the DB (or
other services), how Java apps can pause while getting random data (when
there isn't enough entropy on the system) and when APM / monitoring
solutions are enabled as they add overhead which can be particularly bad
during a busy startup.

At any rate, if you can fix the problem do. That's the best solution. If
slow startup is expected then increase the timeout with the `-t` option to
`cf push`. By default, you can increase it from 60s to 180 seconds.
Operators can increase both the default and max timeout for their platform.

Lastly, `cf set-health-check` is for Diego. To disable the health check
for DEAs, you would just use `cf push --no-route`.

Dan

?
attachment.html

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.