Вопрос или проблема
Я следовал этим шагам, чтобы настроить SystemD в моей дистрибуции WSL2 Ubuntu 20.04 и не подтвердил, как следовало бы, перед перезагрузкой. Теперь, когда я пытаюсь запустить (как обычный пользователь или как root), он зависает с сообщением:
/usr/sbin/enter-systemd-namespace: строка 10: /usr/sbin/daemonize: No such file or directory
Как я могу отменить изменения в /etc/bash.bashrc, чтобы восстановиться? Я пытался редактировать через путь \\wsl$\\<distro>\... из Windows, используя Notepad, но у меня нет разрешений (даже при запуске от имени администратора).
Я вижу, что вы уже восстановились, и это было хорошим решением. В будущем также рассмотрите:
wsl -u root -e bash --noprofile --norc
Это должно привести вас в оболочку без запуска скриптов автозапуска. Если необходимо, можно также использовать sh.
Кроме того, большинство сценариев или инструкций по SystemD для WSL довольно сложны, потому что они пытаются “сделать всё”. Чтобы сделать “быстрый и грязный” SystemD, который работает, но может иметь ограниченный функционал, вы можете начать с:
sudo -b unshare --pid --fork --mount-proc /lib/systemd/systemd --system-unit=multi-user.target
Подождите несколько секунд, чтобы ps -ef “успокоился”, пока SystemD запускается, затем:
sudo -E nsenter --all --wd="$PWD" -t $(pgrep -xo systemd) runuser -P -l $USER -c "exec $SHELL"
Это должно привести вас в пригодную для использования среду SystemD в WSL2/Ubuntu. Основное ограничение заключается в том, что вы не сможете запускать Windows-исполняемые файлы в этой сессии. Но это не должно быть необходимо для учебника по Kubernetes.
Когда у вас это будет работать, тогда вы можете перейти к “полным сценариям SystemD”.
Новая/проблемная строка была строкой 4 в /etc/bash.bashrc.
Мне удалось удалить её из командной строки Windows через:
wsl -u root --exec sed -i 4d /etc/bash.bashrc
Затем я смог снова войти в свою оболочку и очистить проблемы.
В моей дистрибуции Ubuntu (dpkg-query -L daemonize) в WSL daemonize не был в /usr/sbin, но был в /usr/bin. Поэтому измените строку 10 этого файла.
.
Ответ или решение
Для многих пользователей WSL2 (Windows Subsystem for Linux) является мощным инструментом, который позволяет запускать дистрибуции Linux с минимальными усилиями. Однако могут возникнуть проблемы, особенно при настройке сложных системных процессов, таких как SystemD. Одной из таких проблем является ошибочная конфигурация, которая нарушает процесс входа в WSL2. В данном случае, проблема заключается в попытке настроить SystemD для Ubuntu 20.04 в WSL2, что привело к изменению системных файлов, мешающих нормальной загрузке.
Теория
Проблема, с которой сталкивается пользователь, возникает из-за того, что была предпринята попытка включить SystemD, что привело к изменению конфигурационных файлов, например, /etc/bash.bashrc. В результате загрузка системы зависает с ошибкой: /usr/sbin/enter-systemd-namespace: line 10: /usr/sbin/daemonize: No such file or directory. Это происходит потому, что скрипт пытается запустить daemonize из /usr/sbin/, но этот файл там не существует. Аналогичные ситуации часто возникают, когда путь или конфигурация определенных программ указаны неверно, и система не может их найти.
Пример
Давайте рассмотрим, как можно исправить ситуацию. Чтобы избежать исполнения скриптов, которые вызывают ошибку при запуске среды WSL, можно использовать следующую команду:
wsl -u root -e bash --noprofile --norcЭта команда позволяет запустить шелл без загрузки профиля и конфигурационных скриптов, таких как .bashrc или .bash_profile, что может помочь при возникновении ошибок в этих файлах.
Однако, чтобы исправить проблему, вам нужно внести изменения в сам файл /etc/bash.bashrc. Если стандартные средства Windows не позволяют отредактировать необходимый файл из-за проблем с доступом, можно попробовать следующее:
wsl -u root --exec sed -i 4d /etc/bash.bashrcЭта команда удаляет строку 4 в /etc/bash.bashrc, которая вызывает проблему, позволяя вам снова получить доступ к вашей оболочке.
Применение
Теперь, когда вы можете снова войти в систему, исправьте проблему и перейдите к более безопасным способам включения SystemD в WSL2. В некоторых случаях, перемещение бинарного файла daemonize в каталог /usr/sbin/ может решить проблему:
-
Убедитесь, что
daemonizeустановлен в системе. Командойwhich daemonizeпроверьте местонахождение этого бинарного файла. -
Если он находится в
/usr/bin/вместо/usr/sbin/, перенесите его с помощью:sudo mv /usr/bin/daemonize /usr/sbin/daemonize -
Измените конфигурационный файл для правильного указания пути, как это было предложено в описании проблемы.
Кроме того, из предоставленного опыта можно выделить, что при работе с WSL2, важно учитывать особенности совместимости, и заранее тестировать изменения в отдельной тестовой среде, до того как применять их в реальной установке.
Если вас интересует работа с SystemD в WSL2, существуют альтернативные "обходные пути", например, использование контейнеров Docker для выполнения сервиса, который вам нужен, что позволяет обойти некоторые архитектурные ограничения WSL2. Например, для запуска SystemD можно использовать последний метод, описанный в решении:
sudo -b unshare --pid --fork --mount-proc /lib/systemd/systemd --system-unit=multi-user.targetС последующим:
sudo -E nsenter --all --wd="$PWD" -t $(pgrep -xo systemd) runuser -P -l $USER -c "exec $SHELL"Это простой и эффективный способ запустить вашу среду с SystemD без необходимости кардинально менять систему.
WSL2 предоставляет гибкость и мощь Linux на Windows, однако это требует некоторых усилий для сохранения стабильности и производительности среды. Делая изменения в системах, следуйте рекомендациям сообщества и учитывайте опыт коллег, чтобы минимизировать риски.