504 Bad Gateway

[ghost]

HI,

I have recently started using cachet. I am using cachet version 1.2.1. I have set up cachet using docker image. After setup i am able to access my admin page or setup page. But when i go my status page I have a 504 Gateway Timeout Page.(I had the same issue using the cachethq/docker:latest image. )

The following is my docker logs of the cachethq container

Warning: This development build of composer is over 60 days old. It is recommended to update it by running "composer.phar self-update" to get the latest version.
rm -f compiled.php config.php routes.php services.json
Loading composer repositories with package information
Installing dependencies from lock file
Nothing to install or update
Generating optimized autoload files
php artisan optimize --force
Generating optimized class loader
Compiling common classes
php artisan config:cache
Configuration cache cleared!
Configuration cached successfully!
php artisan route:cache
Route cache cleared!
Routes cached successfully!
chmod -R 755 storage
Starting supervisord...
2015-11-26 20:44:22,296 CRIT Supervisor running as root (no user in config file)
2015-11-26 20:44:22,307 INFO RPC interface 'supervisor' initialized
2015-11-26 20:44:22,307 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2015-11-26 20:44:22,307 INFO supervisord started with pid 1
2015-11-26 20:44:23,310 INFO spawned: 'cron' with pid 75
2015-11-26 20:44:23,312 INFO spawned: 'nginx' with pid 76
2015-11-26 20:44:23,313 INFO spawned: 'php5-fpm' with pid 77
2015-11-26 20:44:24,390 INFO success: cron entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2015-11-26 20:44:24,390 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2015-11-26 20:44:24,390 INFO success: php5-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2015-11-26 20:45:04,633 CRIT reaped unknown pid 123)
2015-11-26 20:46:04,752 CRIT reaped unknown pid 136)
2015-11-26 20:47:04,890 CRIT reaped unknown pid 149)
2015-11-26 20:48:05,023 CRIT reaped unknown pid 165)
2015-11-26 20:49:05,173 CRIT reaped unknown pid 184)
2015-11-26 20:50:04,307 CRIT reaped unknown pid 199)

[djdefi]

Hi @crazy9042, did you first initialize the DB?

Are you running this via Docker compose or manually?

[ghost]

@djdefi Hi, Yes I did initialize my DB, And i am running docker manually.

To even verify that i have the DB running properly, I went into the mysql container to see whether the DB was created and it was. It also has the components that i created.

I am able to access my dashboard page, create components, incidents, almost everything but the status page alone shows a 504 Bad Gateway error

[Dids]

I'm seeing the same exact thing. I'm essentially using Docker's Compose (but Tutum instead, which uses the same syntax), and Cachet is running behind Haproxy with port 8000 exposed.

EDIT: Well, not the same exact thing. I actually see the "Houston, we have a problem" page everywhere I go, but it's still Error 500.

[Dids]

Any news on this?

[djdefi]

Is this still occurring with the 2.0.4 release?

[Dids]

My issue seems to stem from my specific environment needs.
I essentially need to customize Cachet enough so that I can effortlessly deploy it anywhere, and even scale it as much as I like, without having to manually configure anything.
So far my issues have been due to redeploying and having to reconfigure the database/Cachet, even though I'm persisting my database data.

[Dids]

Is it possible to configure it once (either through env vars or through a persistent database) and then use the existing data when (re)deploying?

[Dids]

Took the entire day, but I managed to successfully persist the data to a remote database. Redeploying a clean container seems to work nicely too, as long as I pass in all the correct env vars.

[djdefi]

@Dids Glad to hear you got it working. As you have found, there should be no issues with persisting the Database, as long as the correct ENV variables to connect are passed to the Cachet container at runtime.

@crazy9042 Have you been able to test with the latest 2.0.4 release?

[ghost]

@djdefi Hey, Yeah i just tested it today, was able to run cachet and i don't find any 504 errors. But then I do find the following in docker logs.

2016-01-05 16:59:01,325 CRIT reaped unknown pid 104)
2016-01-05 17:00:04,465 CRIT reaped unknown pid 140)
2016-01-05 17:01:04,604 CRIT reaped unknown pid 153)
2016-01-05 17:02:04,742 CRIT reaped unknown pid 166)
2016-01-05 17:03:04,891 CRIT reaped unknown pid 179)
2016-01-05 17:04:05,027 CRIT reaped unknown pid 192)
2016-01-05 17:05:05,173 CRIT reaped unknown pid 205)
2016-01-05 17:06:04,335 CRIT reaped unknown pid 218)
2016-01-05 17:07:04,473 CRIT reaped unknown pid 231)
2016-01-05 17:08:04,618 CRIT reaped unknown pid 244)
2016-01-05 17:09:04,757 CRIT reaped unknown pid 279)
2016-01-05 17:10:04,916 CRIT reaped unknown pid 292)
2016-01-05 17:11:05,049 CRIT reaped unknown pid 305)
2016-01-05 17:12:05,191 CRIT reaped unknown pid 318)
2016-01-05 17:13:04,331 CRIT reaped unknown pid 331)
2016-01-05 17:14:04,531 CRIT reaped unknown pid 344)
2016-01-05 17:15:04,644 CRIT reaped unknown pid 357)

[djdefi]

I believe those can safely be ignored, should just be left over nginx or php-fpm workers that are getting cleaned up.

[ghost]

@djdefi Thanks ryan. I will close this issue for now. In case if i encounter the same i will keep you posted