Глава 11. Устранение неисправностей WSL

Когда дело доходит до установки WSL, она обычно проходит гладко, однако имеется несколько ситуаций, где что- то может пойти не так. В данном разделе мы пройдёмся по некоторым из таких ситуаций и моментам для проверки.

Самый первый момент, который надлежит проверять при проблемах включения WSL состоит в том, что включены необходимые биты Windows. Вы должны обеспечит компоненты Windows с названиями “Virtual Machine Platform” (Платформа виртуальной машины) и “Windows Subsystem for Linux” (Подсистема Windows для Linux). Самый простой способ для осуществления этого, без перемещения по меню, состоит в открытии окна PowerShell от имени Администратора и выполнения двух команд. Эти две команды разрешат необходимые не обязательные функциональные возможности Windows. В качестве альтернативы вы можете воспользоваться диалогом “Turn Windows features on or off” (Включение или отключение компонентов Windows) (Рисунок 11-1).

Для включения необходимых функциональных возможностей Windows с применением PowerShell (Рисунок 11-2), нажмите клавишу Windows на своей клавиатуре и наберите “powershell”:

Некоторые антивирусные приложения сторонних разработчиков могут предотвращать запуск WSL. Наиболее распространённый способ воздействия на WSL это блокирование доступа к “lxcore” или “lxsys”. Они необходимы для правильной работы WSL. Вам следует проверить что они не блокируются вашим антивирусным приложением или что они добавлены в список Допущенных этого приложения.

Завсегда неплохой мыслью будет обеспечение самой последней стартовой площадки для установленного вами дистро. Такой стартовая площадка (launcher) это то, что выполняет выгрузку методами стандартного Windows Store.

Перейдите в запись Windows Store для предпочитаемого вами дистро WSL (Рисунок 11-4) и кликните “Install”, когда он в данный момент не установлен, либо “Update”, если имеются доступными какие бы то ни было обновления.

В качестве альтернативы, перейдите на страницу “Downloads and Updates” Store чтобы посмотреть имеет ли обновления ваш дистро (Рисунок 11-5).

Другой распространённой проблемой, с которой встречаются при запуске внутри виртуальной машины связаны с теми, которые созданы VirtualBox. Пока ваша платформа виртуализации не позволяет вам выставлять вам “nested virtualization”, WSL2 не запустится. Вы можете обнаружить, что вы всё ещё применяете WSL1 при запуске внутри виртуальной машины, поскольку WSL1 не полагается на основанные на аппаратную поддержку технологий виртуализации, порой именуемой как VT-x (название в Intel) или SVM (название в AMD).

Как и все компоненты операционной системы, сама экосистема Linux интенсивно переплетена зависимостями. Многие приложения потребуют включения и нахождения в рабочем состоянии функциональных возможностей. Некоторые из них включают “systemd”, “DBUS” и модулей ядра.

Стандартный механизм для обработки системных служб в дистро Linux обычно предоставляется “Systemd”. Обычно это самый первый процесс, который запускается при загрузке. По причине того как реализованы WSL1 и WSL2, Systemd либо блокируется для запуска, в WSL1, либо требует работы вокруг применения пространства имён процесса в WSL2. При том когда вы испытываете проблему с командой, которая взаимодействует с процессом Systemd, например, systemctl для управления службами, она выдаёт следующее (Рисунок 11-6).

Это указывает на то, что Systemd не работает и что вам требуется отыскать альтернативный способ запуска вашего приложения.

Некоторые приложения будут отказывать в старте пока они не будут запущены через Systemd. Одним из первейших примеров является демон Snapd, который управляет пакетами Snap Linux (за дополнительными сведениями относительно Snap обращайтесь к https://snapcraft.io/). Это означает, что Snap невозможно применять в WSL пока не проработать этот вопрос.

В приложениях с графическим интерфейсом распространено применение службы DBUS для передачи сообщений между приложениями согласованным образом. Обычно служба DBUS запускается и останавливается в вашем сеансе процессом Systemd. В WSL, однако, Systemd пребывает в неработающем состоянии по умолчанию, как это пояснялось ранее. Когда некое приложение пытается применять службу DBUS, оно, скорее всего, испустит сообщение в консоль, указывающее на ошибку или может отказывать в запуске (Рисунок 11-7).

Вы можете исправлять это следующей командой всякий раз когда вы входите в свою среду WSL:

> dbus-launch --exit-with-x11
		

Это может оказаться полезным для добавления в файл .bashrc своего пользователя WSL с тем, чтобы она запускалась всякий раз когда вы запускаете оболочку. Тем не менее, когда вы в самый первый раз испробуете её, вы получите некое сообщение об ошибке (Рисунок 11-8).

Для её исправления выполните следующее (Рисунок 11-9). Это потребуется всего лишь раз:

> sudo dbus-uuidgen –ensure
		

Некоторые приложения могут потребовать включения особенных модулей ядра. Это потребует чтобы вы применяли натуральное ядро Linux с тем чтобы вы могли применять реальные модули ядра Linux. Тем не менее, поддерживаемое Microsoft ядро может не включать тот модуль, которое требует ваше приложение. Вы можете обнаружить это изучив вывод, получаемый при запуске своего приложения на предмет предостерегающих сообщений об ошибках, указывающих на пропущенные модули ядра или вывод dmesg, которая является утилита для отображения внутренних сообщений журнала ядра.

При отказе приложения Linux имеется несколько инструментов, которые вы можете найти полезными:

Наиболее полезным из них для WSL является “strace”, которая позволяет нам наблюдать за системными вызовами, используемыми приложением.

Поскольку WSL1 это уровень трансляции, который был написан с нуля без применения какого бы то ни было исходного кода Linux, некоторые системные вызовы могут оказаться не реализованными. Мы можем воспользоваться “strace” для отслеживания всех системных вызовов, которые некое приложение делает для того чтобы попробовать точно определить пропущенную функциональную возможность в WSL1.

В качестве некого примера рассмотрим случай что мы желаем расследовать системные вызовы ls. Префиксом этой команды при её исполнении мы поставим strace (Рисунок 11-10):

> strace ls
		

Это выдаст большое число регистрируемых сообщений при выполнении данной команды. Может оказаться полезным ограничить отслеживаемые системные вызовы добавляя флаг -e. Наша следующая команда ограничит получаемый вывод только на системные вызовы openat и close (Рисунок 11-11):

> strace -e openat,close ls
		

Вы можете найти перечень системных вызовов Linux в документации “manpage” в https://man7.org/linux/man-pages/man2/syscalls.2.html, или при помощи следующей команды, если вы установили пакет manpages-dev:

> man 2 syscalls
		

Если вы пользуетесь командой man, переместитесь в manpage при помощи кнопок страница вверх и страница вниз или клавишами стрелок и выходите при помощи q.