Как запускать команду при старте WSL через wsl.conf

Что именно означает старт WSL

WSL не является обычной постоянно работающей виртуальной машиной. Экземпляр дистрибутива появляется, когда его запускает пользователь, приложение или команда, а затем может завершиться после отсутствия активных процессов. Поэтому «запуск при старте Windows» и «запуск при старте экземпляра WSL» — разные задачи. Параметр `[boot] command=` выполняется, когда стартует экземпляр WSL; он не создаёт отдельную Windows-службу и сам по себе не гарантирует, что WSL будет поднят сразу после входа в Windows. Это различие важно для локальных веб-серверов, Docker Engine, SSH или скриптов подготовки окружения. Если сервис должен быть доступен ещё до первого ручного открытия WSL, нужен отдельный механизм запуска WSL со стороны Windows.

Важно: Сначала сформулируйте, что вам нужно: команда при старте дистрибутива или автозапуск самого WSL вместе с Windows. Это разные уровни автоматизации.

Настройка boot.command

1. 1. В нужном дистрибутиве откройте `/etc/wsl.conf` от root, например `sudo nano /etc/wsl.conf`. 2. Добавьте секцию `[boot]`. 3. В ней укажите одну команду: `command=service docker start` — это официальный пример Microsoft. Для своего сценария подставьте безопасную команду, которая завершается предсказуемо. 4. Сохраните файл. 5. Из PowerShell выполните `wsl --shutdown`, чтобы остановить WSL 2 и применить конфигурацию при следующем старте. 6. Снова откройте дистрибутив и проверьте состояние сервиса или результат команды. 7. Если команда пишет лог, проверьте его отдельно: отсутствие текста в интерактивном терминале не доказывает, что она не выполнялась.

Предупреждение: Boot-команда запускается как root. Не добавляйте туда `sudo` и не запускайте непроверенный скрипт, который получит системные права автоматически.

Когда лучше использовать systemd

Если задача состоит в запуске одного Linux-сервиса с рестартом, зависимостями, журналом и порядком запуска, systemd обычно удобнее голой boot-команды. В WSL 2 его можно включить в том же `/etc/wsl.conf` через `[boot] systemd=true`, после чего пользоваться `systemctl enable <service>` и `systemctl status <service>`. Это позволяет описать зависимости от сети, файловых систем и других unit, а ошибки смотреть в journal. Boot-команда остаётся полезной для коротких действий: выставить параметр, подготовить каталог, запустить совместимый legacy service script. Не нужно одновременно запускать один и тот же демон через `command=` и `systemctl enable`: получите гонку, дублирование процесса или ошибку «address already in use».

Совет: Для долгоживущего сервиса выбирайте один механизм управления. Дублирование автозапуска сложнее диагностировать, чем отсутствие автозапуска.

Какой механизм выбрать

• Одна короткая root-команда | `[boot] command=` | Минимум конфигурации
• Сервис с зависимостями и логами | systemd unit | Управление через systemctl/journalctl
• Нужно поднять WSL сразу при входе в Windows | Windows Task Scheduler/другой Windows-механизм + запуск WSL | Это уже запуск WSL, а не только Linux boot
• Команда нужна только в интерактивном shell | `.bashrc`/профиль shell | Не путать с системным стартом

Почему команда не срабатывает

Первая причина — WSL не был полностью перезапущен после правки файла. Вторая — синтаксическая ошибка в `/etc/wsl.conf` или команда, которая ожидает интерактивный ввод. Третья — вы проверяете не тот дистрибутив: `wsl -l -v` покажет установленные системы, а `/etc/wsl.conf` действует только внутри текущей. Ещё одна типичная ошибка — использовать относительный путь к своему скрипту. Boot-команда запускается в системном контексте, поэтому задавайте абсолютные пути и не рассчитывайте на пользовательский `$PATH`, алиасы из `.bashrc` или активированное Python-окружение. Для диагностики временно направьте stdout и stderr в файл, например через shell-обёртку, а после исправления уберите лишний лог.

Минимальная самопроверка

• правится `/etc/wsl.conf` именно нужного дистрибутива
• после изменения выполнен `wsl --shutdown`
• boot-команда не требует интерактивного ввода
• используются абсолютные пути
• один сервис не запускается двумя механизмами одновременно
• результат проверяется по process/status/log, а не только по отсутствию ошибок на экране

Логи и идемпотентность команды запуска

Команда из `[boot]` должна безопасно переносить повторные старты WSL. Практически это означает, что скрипт не должен безусловно создавать один и тот же ресурс, дублировать строки конфигурации или запускать второй экземпляр процесса при каждом старте дистрибутива. Для собственного скрипта используйте абсолютные пути, явный код возврата и журнал, например перенаправление вывода в файл под `/var/log`, чтобы не гадать, запускалась ли команда вообще. Если команда поднимает сетевую службу, отдельно проверьте, что нужный интерфейс и DNS уже доступны в момент выполнения: запуск дистрибутива и готовность внешней сети — не одно и то же событие. Для долгоживущих демонов предпочтительнее systemd unit с политикой перезапуска и журналом `journalctl`, если systemd включён. `boot.command` удобнее для короткой подготовки окружения или запуска простого идемпотентного сценария.

Как сделать boot-команду предсказуемой и диагностируемой

Команда в `[boot]` выполняется как root, поэтому лучше запускать короткий проверяемый скрипт, а не длинную цепочку команд прямо в `wsl.conf`. Например, разместите скрипт в `/usr/local/sbin/`, дайте ему понятное имя и сделайте его идемпотентным: повторный запуск не должен дублировать строки, создавать второй процесс или ломать уже существующий ресурс. Для диагностики перенаправляйте обычный вывод и ошибки в отдельный лог-файл либо используйте системный журнал, если задача оформлена как systemd-unit. После изменения конфигурации обязательно выполните `wsl --shutdown`, затем запустите нужный дистрибутив и проверьте побочный эффект команды, а не только отсутствие ошибки в терминале. Если требуется последовательность сервисов, рестарты, зависимости `After=` или автоматический перезапуск после сбоя, переносите задачу в systemd: `[boot] command=` удобен для простого однократного действия, но не заменяет менеджер служб. И отдельно помните: эта настройка срабатывает при старте экземпляра WSL, а не автоматически при каждом входе пользователя в Windows.

Что учитывать

Первая причина — WSL не был полностью перезапущен после правки файла. Вторая — синтаксическая ошибка в `/etc/wsl.conf` или команда, которая ожидает интерактивный ввод. Третья — вы проверяете не тот дистрибутив: `wsl -l -v` покажет установленные системы, а `/etc/wsl.conf` действует только внутри текущей. Ещё одна типичная ошибка — использовать относительный путь к своему скрипту. Boot-команда запускается в системном контексте, поэтому задавайте абсолютные пути и не рассчитывайте на…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Advanced settings configuration in WSL). Пример и формулировки — редакция N1RO на 2026-09-20.

• Advanced settings configuration in WSL