Как справиться с состоянием «Выход 0» в Docker

#docker #docker-compose #exit #entry-point #docker-container

#docker #docker-compose #выход #точка входа #докер-контейнер

Вопрос:

Я создал образ Docker, а затем запустил контейнер с помощью Docker Compose. Следующая команда выполнит эту работу за меня:

 docker-compose up -d
  

Я перезапустил компьютер, и теперь я хочу запустить предыдущий контейнер, который я создал ранее. Итак, я попробовал следующую команду:

 $ docker-compose start 
Starting php-apache ... done
  

По-видимому, это работает, но это не соответствует выводам для следующей команды:

 $ docker-compose ps
          Name                         Command               State    Ports 
---------------------------------------------------------------------------
php55devwork_php-apache_1   /bin/sh -c bash -C '/usr/l ...   Exit 0        
  

Наверняка что-то не так, и я пытаюсь выяснить, что.

  • Как мне найти причину сбоя команды?
  • Есть ли какое-либо место, где я мог бы увидеть файл журнала или что-то, что помогло бы мне идентифицировать и исправить ошибку?

Вот репозиторий, если вы хотите попробовать.

Обновить

Если я удалю контейнер: docker rm <container-id> и воссоздам его, запустив docker-compose up -d --build , он снова заработает.

Обновление # 1

Я не могу видеть такие странные символы:

введите описание изображения здесь

Ответ №1:

Это то, что помогло мне решить эту проблему: в одной из ваших служб в файле docker-compose yaml введите следующее:

tty: true итак, это будет выглядеть так

 version: '3'

services: 
   web: 
     tty: true
  

Надеюсь, это кому-то поможет; спасибо, если это поможет вам 🙂

Комментарии:

1. Потратил 2 часа, чтобы найти, как настроить контейнер Ubuntu из-за кода выхода 0, и это решило проблему, спасибо

Ответ №2:

Я заглянул в ваш Docker github и setup_php_settings в строке (строка № 27) есть source /etc/apache2/envvars amp;amp; exec /usr/sbin/apache2 -DFOREGROUND

и это выполняется apache2 на переднем плане, поэтому оно не должно завершаться со статусом code 0 .

Но мне кажется, что ваш setup_php_settings содержит какой-то странный символ (когда я запускаю ваше изображение с помощью compose) (оригинал находится справа) странный символ, я изменил его на новые строки, и это сработало для меня. Дайте нам знать, помогло ли это.

Если вы хотите отладить свой контейнер docker, вы можете запустить его без точки входа, например:

docker run -it yourImage bash


— ПОСЛЕ некоторого расследования:

При перезапуске контейнера docker все еще возникали некоторые ошибки — например, в вашем случае остановленный контейнер и запуск после перезагрузки. Возникли проблемы: символические ссылки уже существуют, а apache2 имеет раздражающий PID, поэтому нам нужно сделать что-то вроде официального php docker

Это полностью setup_php_settings сработало для меня после перезапуска контейнера.

 #!/bin/bash -x
set -e

PHP_ERROR_REPORTING=${PHP_ERROR_REPORTING:-"E_ALL amp; ~E_DEPRECATED amp; ~E_NOTICE"}
sed -ri 's/^display_errorss*=s*Off/display_errors = On/g' /etc/php5/apache2/php.ini
sed -ri 's/^display_errorss*=s*Off/display_errors = On/g' /etc/php5/cli/php.ini
sed -ri "s/^error_reportings*=.*$//g" /etc/php5/apache2/php.ini
sed -ri "s/^error_reportings*=.*$//g" /etc/php5/cli/php.ini
echo "error_reporting = $PHP_ERROR_REPORTING" >> /etc/php5/apache2/php.ini
echo "error_reporting = $PHP_ERROR_REPORTING" >> /etc/php5/cli/php.ini

mkdir -p /data/tmp/php/uploads
mkdir -p /data/tmp/php/sessions
mkdir -p /data/tmp/php/xdebug

chown -R www-data:www-data /data/tmp/php*

ln -sf /etc/php5/mods-available/zz-php.ini /etc/php5/apache2/conf.d/zz-php.ini
ln -sf /etc/php5/mods-available/zz-php-directories.ini /etc/php5/apache2/conf.d/zz-php-directories.ini

# Add symbolic link to get Zend out of the current install dir
ln -sf /usr/share/php/libzend-framework-php/Zend/ /usr/share/php/Zend

a2enmod rewrite
php5enmod mcrypt

# Apache gets grumpy about PID files pre-existing
: "${APACHE_PID_FILE:=${APACHE_RUN_DIR:=/var/run/apache2}/apache2.pid}"
rm -f "$APACHE_PID_FILE"

source /etc/apache2/envvars amp;amp; exec /usr/sbin/apache2 -DFOREGROUND "$@"
  

Комментарии:

1. Это странно. Я их не вижу, какой инструмент вы использовали? Я нахожусь в Fedora, используя редактор Atom. Что касается ошибок, должны ли они останавливать контейнер при запуске?

2. Я обновил OP с изображением, я не могу видеть эти странные символы

3. TurtoiseGit но я в Windows. Как я видел, вы поняли это, но это странно.

4. @ReynierPM Вероятно, это ошибка Windows. Но когда я перезапускаю контейнер, он завершается с ошибкой, как в вашем случае

5. @ReynierPM Я добавил, setup_php_settings что у меня тоже сработало после перезапуска контейнера без перестройки.

Ответ №3:

Вы можете проверить журналы с помощью docker compose logs .

Просматривая ваше репозиторий, у вас есть

 ENTRYPOINT bash -C '/usr/local/bin/setup_php_settings';'bash'
  

которое без интерактивного сеанса bash завершит работу немедленно (с кодом выхода 0) после чтения конца файла на стандартном сервере.

Комментарии:

1. Я считаю, что это проблема, но я не знаю, как это исправить, не могли бы вы помочь мне решить эту проблему? Я начинаю изучать Docker 🙂

2. Точка входа не должна выходить, поэтому ENTRYPOINT /usr/local/bin/setup_php_settings amp;amp; sleep infinity может работать.

Ответ №4:

Обычно получение exit 0 должно быть поводом для празднования, поскольку это указывает на то, что ваша команда успешно завершилась (http://www.tldp.org/LDP/abs/html/exit-status.html).

Взглянув на ваш Dockerfile , похоже, что вы просто вызываете bash в своей точке входа, которая затем наверняка завершится (поскольку она не блокируется). Для того, чтобы обслуживать некоторые данные, вы должны скорее вызывать php (это операция блокировки, которая поддерживает работу контейнера), как это сделано в официальных файлах docker для php (см. CMD ["php", "-a"] На https://github.com/docker-library/php/blob/1c56325a69718a3e3cf76179e75d070b7e23da62/5.6/Dockerfile )

Комментарии:

1. Должен ли я изменить свой ENTRYPOIN T на ENTRYPOINT bash -C '/usr/local/bin/setup_php_settings';'php -a' вместо этого? Это то, что вы сказали?

2. Ага, но обязательно попробуйте то, что выяснил VladoDemcak.