Сообщение Running in chroot, ignoring command 'start' появляется при попытке запустить службу через systemctl start или service ... start внутри окружения chroot — например, при восстановлении системы с LiveUSB, при сборке пакетов или при установке дистрибутива вручную. Это не ошибка в строгом смысле: система инициализации обнаружила, что работает в изолированном корневом каталоге, и сознательно проигнорировала команду запуска демона.
Такое поведение заложено намеренно. В chroot нет полноценного процесса systemd с PID 1, который мог бы принять команду и управлять юнитами, поэтому попытка «запустить» сервис не имеет смысла — ему просто некому подчиняться. Ниже разберём, почему возникает это сообщение, когда его можно игнорировать, а когда нужно действовать, и как правильно управлять службами внутри chroot-окружения.
Почему systemd отказывается выполнять команду в chroot
Утилита systemctl взаимодействует с системным менеджером через шину D-Bus и сокет /run/systemd/private. Внутри chroot этот сокет либо отсутствует, либо указывает на «чужой» экземпляр systemd хост-системы, управлять которым из изолированного окружения было бы небезопасно. Поэтому инструменты инициализации определяют факт работы в chroot и блокируют команды start, stop и restart.
Обнаружение chroot происходит простым способом: сравнивается корневой каталог текущего процесса с корнем процесса с PID 1. Если они различаются — значит, процесс находится в сменённом корне. Аналогичную проверку выполняет скрипт /usr/sbin/policy-rc.d в Debian-подобных системах и обёртка invoke-rc.d, которые могут полностью запрещать запуск служб при установке пакетов в chroot.
Важно понимать: команды enable и disable при этом обычно работают, потому что они лишь создают или удаляют символические ссылки в каталогах /etc/systemd/system/ и не требуют запущенного менеджера. Игнорируются именно команды управления состоянием процесса.
Когда сообщение можно спокойно игнорировать
В ряде сценариев сообщение — нормальная часть рабочего процесса, и предпринимать ничего не нужно. Типичные случаи:
- 🔧 Вы chroot-нулись в установленную систему с LiveUSB для восстановления загрузчика и попутно пытаетесь перезапустить сервис — после перезагрузки в основную систему службы стартуют штатно.
- 📦 Сборка пакетов в pbuilder, sbuild или mock: postinst-скрипты пытаются запустить демоны, но это и не требуется в сборочном окружении.
- 🐳 Подготовка rootfs для контейнера или встраиваемой системы, где службы будут запущены уже на целевом устройстве.
- 💾 Установка дистрибутива вручную (например, Arch Linux через
arch-chroot): достаточно включить нужные юниты черезsystemctl enable, а запуск произойдёт при первой загрузке.
Проверьте, какая именно команда была проигнорирована. Если это start или restart внутри скрипта установки пакета — пакет, скорее всего, установился корректно, и служба поднимется после выхода из chroot и перезагрузки.
⚠️ Внимание: не путайте игнорирование командыstartс реальной ошибкой установки пакета. Если установщик завершился с ненулевым кодом возврата из-за невозможности запустить службу, проверьте настройкиpolicy-rc.d— возможно, скрипту нужно явно разрешить «молчаливый» пропуск запуска.
Как проверить, что вы действительно в chroot
Прежде чем что-то исправлять, убедитесь, что окружение — действительно chroot, а не полноценная система с другой проблемой. Есть несколько способов диагностики.
Самый прямой — сравнить корневые каталоги процессов:
ls -di /
ls -di /proc/1/root/
Если иноды различаются, процесс с PID 1 видит другой корень — вы в chroot. Дополнительно можно проверить, запущен ли systemd как PID 1:
ps -p 1 -o comm=
systemctl is-system-running
Команда systemctl is-system-running в chroot обычно возвращает offline или ошибку подключения к шине, что подтверждает отсутствие работающего менеджера. Также полезно посмотреть переменную окружения SYSTEMD_IGNORE_CHROOT и файл /run/systemd/container, если речь идёт о контейнере.
Способы запустить службу внутри chroot
Иногда процесс внутри chroot всё же нужен — например, вы тестируете конфигурацию nginx или базы данных перед переносом системы. Поскольку systemd недоступен, используются обходные пути.
Первый вариант — запустить демон напрямую, минуя систему инициализации. У большинства сервисов есть бинарный файл, который можно вызвать вручную с нужными параметрами:
/usr/sbin/nginx -c /etc/nginx/nginx.conf
/usr/sbin/sshd -D &
Второй вариант — использовать классические init-скрипты /etc/init.d/, если они сохранились в пакете. Многие из них способны запустить демон без участия systemd:
/etc/init.d/ssh startТретий подход — вместо chroot применить systemd-nspawn, который создаёт лёгкий контейнер с полноценным (или частичным) менеджером внутри:
systemd-nspawn -D /mnt/system --bootВ таком окружении systemctl start работает почти как в обычной системе. Это удобно для тестирования, но требует совместимого дерева каталогов с установленным systemd.
Управление автозапуском без запуска: enable и маскировка
Если цель — подготовить систему в chroot к загрузке, запускать службы не нужно вообще. Достаточно настроить автозапуск, и всё поднимется при старте целевой системы.
systemctl enable sshd
systemctl enable NetworkManager
systemctl disable bluetooth
Эти команды создают или удаляют симлинки в /etc/systemd/system/*.target.wants/ и полностью работоспособны в chroot. Проверить результат можно командой systemctl is-enabled имя_службы — она тоже не требует запущенного менеджера.
☑️ Подготовка служб в chroot перед первой загрузкой
Для блокировки службы используйте systemctl mask — она создаёт симлинк на /dev/null и гарантированно запрещает запуск даже как зависимость. Это тоже файловая операция, доступная в chroot.
Типичные ошибки при работе в chroot
Многие проблемы в chroot связаны не с самим сообщением, а с неправильно подготовленным окружением. Перед входом через chroot /mnt необходимо примонтировать виртуальные файловые системы, иначе даже разрешённые команды будут вести себя непредсказуемо.
| Ошибка | Признак | Решение |
|---|---|---|
| Не примонтирован /proc | Команды ps, top не работают | mount -t proc proc /mnt/proc |
| Не примонтирован /dev | Ошибки доступа к устройствам | mount --bind /dev /mnt/dev |
| Не примонтирован /sys | Нет информации об оборудовании | mount --bind /sys /mnt/sys |
| Неверный DNS в chroot | Не резолвятся домены | Скопировать /etc/resolv.conf |
| Попытка systemctl start | «Running in chroot, ignoring command» | Использовать enable или запуск вручную |
⚠️ Внимание: не запускайте внутри chroot команды, меняющие состояние оборудования хоста, — например, systemctl reboot или операции с разделами диска. Даже если часть команд игнорируется, прямой вызов бинарных утилит может затронуть основную систему, поскольку ядро у chroot и хоста общее.
Отличия в контейнерах и при systemd-firstboot
Похожее сообщение встречается и в контейнерах Docker или LXC, где systemd либо отсутствует, либо работает в урезанном режиме. Там логика та же: без PID 1 в роли менеджера команды start бессмысленны. В контейнерах принято запускать главный процесс приложения напрямую через ENTRYPOINT, а не через систему инициализации.
При первой загрузке свежеразвёрнутой системы настройку служб можно делегировать механизму systemd-firstboot и preset-файлам, которые применяют политику автозапуска автоматически. Это избавляет от необходимости вручную включать юниты в chroot на этапе подготовки образа.
Почему enable работает, а start — нет
Команды enable/disable/mask лишь манипулируют символическими ссылками в /etc/systemd/system/ — это обычные файловые операции, не требующие связи с менеджером. Команды start/stop/restart отправляют запрос через D-Bus запущенному systemd (PID 1), которого в chroot нет, поэтому запрос отклоняется с сообщением об игнорировании.
Порядок действий при восстановлении системы через chroot
Типовой сценарий, где пользователи чаще всего видят это сообщение, — восстановление незагружающейся системы с LiveUSB. Правильная последовательность выглядит так.
- Примонтируйте корневой раздел:
mount /dev/sdXN /mnt(подставьте свой раздел). - Подключите служебные ФС:
for d in /dev /dev/pts /proc /sys /run; do mount --bind $d /mnt$d; done. - Войдите в окружение:
chroot /mnt /bin/bash. - Выполните нужные действия: переустановите загрузчик, обновите initramfs, включите службы через
systemctl enable. - Выйдите (
exit), отмонтируйте разделы в обратном порядке и перезагрузитесь.
На шаге 4 не пытайтесь «проверить» службу командой start — она будет проигнорирована, и это ожидаемо. Реальную проверку выполняйте уже после загрузки в восстановленную систему.
Часто задаваемые вопросы
Это сообщение — ошибка, которую нужно исправлять?
Нет. Это информационное предупреждение о том, что команда запуска службы проигнорирована из-за работы в chroot. Само по себе оно не свидетельствует о поломке. Исправлять нужно только если вы ожидали, что служба реально запустится, — тогда используйте ручной запуск демона или systemd-nspawn.
Служба запустится после перезагрузки, если в chroot она не стартовала?
Да, если она включена в автозагрузку. Проверьте это командой systemctl is-enabled имя_службы. При ответе enabled служба стартует штатно при загрузке целевой системы, где systemd работает как PID 1.
Можно ли заставить systemctl start работать в chroot?
Напрямую — нет, это сознательное ограничение. Обходные варианты: запустить бинарник демона вручную, использовать init-скрипты из /etc/init.d/ или заменить chroot на systemd-nspawn --boot, где менеджер служб функционирует.
Почему установка пакета в chroot завершается с ошибкой из-за этого сообщения?
Некоторые postinst-скрипты считают неудачный запуск службы фатальным. В Debian-подобных системах проблему решает файл /usr/sbin/policy-rc.d с кодом выхода 101 — он штатно запрещает запуск демонов, и скрипты завершаются успешно.
Опасно ли игнорировать это сообщение при восстановлении системы?
Нет, если вы осознанно работаете в chroot и ваша задача — настройка, а не запуск служб. Опасность представляют другие действия: операции с разделами, сетевыми интерфейсами и ядром, которые из chroot влияют на хост-систему, поскольку ядро общее.