instanceIdleTimeout в WSL: таймер остановки дистрибутива

Что регулирует instanceIdleTimeout

Параметр полезен, когда WSL-дистрибутив завершается после периода без активности, а вам нужно изменить это поведение для фонового сценария. Microsoft задаёт `instanceIdleTimeout` в миллисекундах и размещает его среди общих настроек WSL. По умолчанию указано 15000 мс, то есть 15 секунд, а `-1` отключает auto-shutdown, связанный именно с этим таймером. Это не означает, что любой Linux-процесс гарантированно будет жить бесконечно: на жизненный цикл могут влиять остановка WSL пользователем, перезагрузка Windows, обновления и другие механизмы. Поэтому настройку нужно оценивать через реальный сервис или job, который вы хотите сохранить после закрытия терминала.

Совет: Перед изменением воспроизведите исходное поведение: закройте shell-окна и зафиксируйте, через какое время дистрибутив исчезает из `wsl --list --running`.

instanceIdleTimeout и vmIdleTimeout — не одно и то же

В той же документации есть `vmIdleTimeout`, но это другой уровень. `instanceIdleTimeout` находится в `[general]` и описывает, сколько дистрибутив остаётся неактивным до завершения; `vmIdleTimeout` находится в `[wsl2]` и относится к виртуальной машине WSL 2. Для `vmIdleTimeout` Microsoft указывает значение по умолчанию 60000 мс. Если менять оба параметра одновременно, результат становится трудно объяснить: вы не узнаете, какой таймер повлиял на наблюдение. При диагностике сначала измените только `instanceIdleTimeout`, перезапустите WSL и повторите одинаковый тест. Только если задача действительно касается жизненного цикла всей VM, исследуйте `vmIdleTimeout` отдельно.

Предупреждение: Не копируйте значения одного idle-параметра в другой по аналогии. Для instanceIdleTimeout отключение auto-shutdown явно документировано как `-1`; семантика vmIdleTimeout отдельная.

Сравнение двух таймеров

• instanceIdleTimeout. [general]. дистрибутив. 15000 мс
• instanceIdleTimeout=-1. [general]. дистрибутив. отключить auto-shutdown по этому таймеру
• vmIdleTimeout. [wsl2]. WSL 2 VM. 60000 мс

Важно: Если задача — сохранить один конкретный дистрибутив активным, сначала тестируйте instanceIdleTimeout отдельно. Изменять оба idle-параметра одновременно — плохой диагностический эксперимент.

Как выбрать значение в миллисекундах

Перевод простой: секунды × 1000. Например, 60 секунд — 60000 мс, 5 минут — 300000 мс. Выбирайте значение от реальной паузы между событиями фонового процесса, а не из случайного примера. Если job получает задачу примерно раз в минуту, таймер 20 секунд будет конфликтовать с ожиданием; если процесс нужен только интерактивно, бесконечное `-1` может быть излишним. Увеличенный таймер способен удерживать дистрибутив активным дольше, а значит сохранять связанные процессы и потребление ресурсов. Это не ошибка, но компромисс должен быть осознанным. Для сервера разработчика разумно сначала попробовать конечный интервал и только затем переходить к `-1`.

Как изменить таймер и проверить его

1. 1: Сохраните незавершённую работу в WSL и запишите текущее состояние `wsl --list --running`.
2. 2: Откройте `%UserProfile%\.wslconfig` и в секции `[general]` задайте, например, `instanceIdleTimeout=60000` для 60 секунд либо `-1` для отключения этого auto-shutdown.
3. 3: Сохраните конфиг и выполните `wsl --shutdown`, затем снова запустите тестовый дистрибутив.
4. 4: Запустите именно тот фоновый сценарий, ради которого меняется настройка, и убедитесь, что он работает до закрытия терминала.
5. 5: Закройте интерактивные shell-окна и наблюдайте `wsl --list --running` и сам сервис из внешнего клиента.
6. 6: Повторите тест с исходным значением, если нужно доказать причинную связь, а не случайное изменение поведения.

Почему фоновый процесс меняет результат

«Я ничего не делаю в терминале» и «дистрибутив idle» — не обязательно одно и то же. systemd-сервис, Docker-процесс, watcher, cron-задача или открытое сетевое соединение могут поддерживать активность. Поэтому тест, где в одном варианте запущен сервер, а в другом нет, нельзя использовать для сравнения таймера. Подготовьте два одинаковых прогона. Если ваша реальная цель — держать daemon постоянно доступным, проверяйте его как daemon: после закрытия терминала обращайтесь к порту или health endpoint и смотрите статус WSL из PowerShell. Если нужен только быстрый повторный запуск shell, измеряйте время до остановки без фоновых сервисов. Так вы не приписываете таймеру поведение другого процесса.

Что не решает instanceIdleTimeout

Параметр не превращает WSL в автономную серверную VM, которая обязана переживать выход пользователя, перезагрузку Windows или команду `wsl --shutdown`. Он также не заменяет настройки автозапуска Linux-сервисов. Если после перезагрузки Windows приложение не стартует, это отдельная задача запуска сервиса, а не величины idle timeout. Если WSL потребляет много памяти, не пытайтесь лечить это уменьшением таймера без измерений: причина может быть в workload, кэше или настройках памяти. И наоборот, `-1` стоит использовать только когда вы действительно хотите исключить auto-shutdown по этому таймеру. Узкая настройка должна решать узкую наблюдаемую проблему.

Чек-лист корректного эксперимента

• редактируется `%UserProfile%\.wslconfig`, а не `/etc/wsl.conf`
• `instanceIdleTimeout` находится в `[general]`
• значение рассчитано в миллисекундах
• после правки выполнен `wsl --shutdown`
• в обоих прогонах одинаковый набор фоновых процессов
• проверяется тот же дистрибутив
• `vmIdleTimeout` не меняется одновременно
• отдельно учтены ручной shutdown и перезагрузка Windows

Как выбрать между конечным таймером и -1

Конечное значение удобнее, если процесс должен переживать короткие паузы, но вам не нужна постоянно работающая WSL-среда. `-1` уместен, когда именно автоматическое завершение простаивающего дистрибутива мешает стабильному фоновому сценарию и вы готовы явно останавливать WSL при необходимости. После периода реальной работы проверьте, достигнута ли цель и не появились ли побочные эффекты: забытые dev-сервисы, неожиданные открытые порты или ненужное потребление ресурсов. Если задача исчезла после обновления приложения или архитектуры проекта, верните default. Минимальная конфигурация проще для поддержки, а документированные 15000 мс дают понятную исходную точку для повторного теста.

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

«Я ничего не делаю в терминале» и «дистрибутив idle» — не обязательно одно и то же. systemd-сервис, Docker-процесс, watcher, cron-задача или открытое сетевое соединение могут поддерживать активность. Поэтому тест, где в одном варианте запущен сервер, а в другом нет, нельзя использовать для сравнения таймера. Подготовьте два одинаковых прогона. Если ваша реальная цель — держать daemon постоянно доступным, проверяйте его как daemon: после закрытия терминала обращайтесь к порту или health endpoint…

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

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

• Advanced settings configuration in WSL