Docker: App container crashing using full + compose examples

Created on 28 Aug 2019  路  2Comments  路  Source: nextcloud/docker

Hi, I'm trying to setup my NextCloud using the docker compose example for nginx-proxy/mariadb-cron-redis/fpm. For the NextCloud image, I'm building my own using the full/fpm-alpine example Dockerfile, because I would like to install LibreOffice. However, this combination is causing the NextCloud app container to enter a crash loop when I execute docker-compose up -d. The only change I made was to the docker-compose.yml to use my image for web and cron + setting the environment vars. If I leave the docker-compose.yml as is where it is using the nextcloud:fpm-alpine image, it runs fine. I've been at this for couple of hours now, any suggestions on what I maybe doing incorrectly would be really appreciated. Here's what I see in the docker logs for the app container.

docker logs -ft nextcloud_app_1 
2019-08-28T01:53:55.609183422Z Configuring Redis as session handler
2019-08-28T01:53:55.839298076Z /usr/lib/python2.7/site-packages/supervisor/options.py:461: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
2019-08-28T01:53:55.839328773Z   'Supervisord is running as root and it is searching '
2019-08-28T01:53:56.851836938Z Configuring Redis as session handler
2019-08-28T01:53:57.096103131Z /usr/lib/python2.7/site-packages/supervisor/options.py:461: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
2019-08-28T01:53:57.096131614Z   'Supervisord is running as root and it is searching '
2019-08-28T01:53:57.099474899Z Unlinking stale socket /run/supervisord.sock
2019-08-28T01:53:58.260561818Z Configuring Redis as session handler
2019-08-28T01:53:58.492818686Z /usr/lib/python2.7/site-packages/supervisor/options.py:461: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
2019-08-28T01:53:58.492849843Z   'Supervisord is running as root and it is searching '
2019-08-28T01:53:58.496005263Z Unlinking stale socket /run/supervisord.sock
2019-08-28T01:53:59.878067813Z Configuring Redis as session handler
2019-08-28T01:54:00.113448900Z /usr/lib/python2.7/site-packages/supervisor/options.py:461: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
2019-08-28T01:54:00.113478285Z   'Supervisord is running as root and it is searching '
2019-08-28T01:54:00.116836401Z Unlinking stale socket /run/supervisord.sock
...
...

Most helpful comment

After a good night of sleep and refresh mind in the morning, here's what I've discovered. Some where along the line, a /etc/supervisord.conf was introduced into the docker image. It caused the /usr/bin/supervisord command to default to that conf file instead of the one provided in the /etc/supervisord folder. I simply changed last COPY in the docker file to COPY supervisord.conf /etc/supervisord.conf. Now the container is no longer crashing. I guess I could also delete the default one in /etc folder, or use the -c option to specify the conf file path. Would be great if you guys can update the example so other folks don't have to spent time figuring this out again. Thanks for all the great works you guys have put in!

All 2 comments

After a good night of sleep and refresh mind in the morning, here's what I've discovered. Some where along the line, a /etc/supervisord.conf was introduced into the docker image. It caused the /usr/bin/supervisord command to default to that conf file instead of the one provided in the /etc/supervisord folder. I simply changed last COPY in the docker file to COPY supervisord.conf /etc/supervisord.conf. Now the container is no longer crashing. I guess I could also delete the default one in /etc folder, or use the -c option to specify the conf file path. Would be great if you guys can update the example so other folks don't have to spent time figuring this out again. Thanks for all the great works you guys have put in!

PRs are welcomed :wink:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

k1ngf15h3r picture k1ngf15h3r  路  3Comments

gjedeer picture gjedeer  路  3Comments

DisasteR picture DisasteR  路  3Comments

pr4xx picture pr4xx  路  4Comments

alexbarnhill picture alexbarnhill  路  3Comments