В тестовой сборке Windows 10 появилась возможность автоматически выполнять команды Linux при запуске дистрибутивов в WSL


    С помощью использования новой функции в WSL можно, например, фиксировать время и дату запусков дистрибутивов Linux в WSL.

    6 января 2021 года Microsoft рассказала в своем блоге, что в тестовой сборке Windows 10 Insider build 21286 появилась возможность автоматически выполнять команды Linux при запуске дистрибутивов Linux в подсистеме Windows для Linux (WSL).

    Microsoft пояснила, что ее разработчики добавили в настройки WSL параметр, который позволяет запускать необходимую команду Linux при запуске дистрибутива WSL. Это можно сделать путем редактирования файла /etc/wsl.conf в дистрибутиве и создания там параметра под названием “command” (команда) в раздел под названием “boot” (загрузка).

    После внесения изменений данная команда будет автоматически запускаться всякий раз, когда запускается определенный дистрибутив WSL.

    Microsoft уточнила, что дистрибутивы WSL продолжают работать в течение нескольких минут даже после закрытия последнего процесса Linux внутри них. Чтобы проверить, работает ли еще дистрибутив WSL, нужно запустить в PowerShell команду «wsl --list --verbose». Чтобы вручную закрыть дистрибутив WSL, нужно использовать команду «wsl --shutdown».

    В октябре прошлого года пользователи обнаружили, что подсистема WSL 2 обходит правила блокировки встроенного брандмауэра Windows 10. В то время, как первая версия WSL полностью соблюдает все ограничения Windows Advanced Firewall (WAF).
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 32

      +2
      А что, остальных способов было недостаточно? Например .bashrc, cron...?
        +2
        Они не были разработаны Microsoft.
          +2
          EEE недостаточно быстрым получается и конфигурирование слишком привязано к общепринятым стандартам, а нужно чтобы было привязано к WSL. И чтобы не не имело «фатального недостатка». То есть все механизмы должны быть либо написаны в Microsoft либо должны находиться под контролем Microsoft. Если есть конкурирующие стандарты вроде cron и systemd timers то надо сделать третий, но свой )) Не делать же вместо этого поддержку зловредного тяжелого systemd — пускай этим сторонние разработчики на Гитхабе занимаются и всякие маргинальные RHEL и Ubuntu его развивают ))

          По сути дела в применении к WSL это будет больше похоже выполнение команд подобно тому как гипервизоры позволяют делать по ssh после запуска системы или через свои API. Только почему-то вместо ssh используется файл внутри гостевой машины. Возможно здесь идея в том, что эти команды выполняются еще до старта сервисов, включая демон ssh? Или в том, что ssh поднимать не нужно? Но уход в сторону решений от MS вопросы вызывает. Общая тенденция просто наблюдается — уводить в сторону W от L, чтобы подсевших на WSL не тянуло базовые навыки по L получать, а то пойдут девелоперс неправильной дорогой ))
            +3
            Идея тут в том, что этот конфиг читает init процесс, который в WSL является pid 1. Systemd у них нет, автозапуска и init системы полноценной тоже. До этого были костыли с bashrc. Теперь будет лучше. И никакой EEE тут не при чем.
              +1
              В WSL нет systemd? Серьёзно?
                0
                Наверное, мог бы быть, но кто его запустит? bashrc?
                  +1
                  Внезапно linux kernel.
                    0

                    А разве это не виртуальная машина с модифицированной Ubuntu или иным дистрибутивом?

                      0
                      Я работал только с WSL1 и активно пользовался его возможностью запускать процессы между подсистемами. Скажем, я могу встроить dcclinux.exe в makefile, стартующий из WSL. И линукс32 трансляторы, стартующие из Windows IDE. Или транслятор в Си, который после того, как в Си перевёл, вызывает собственно транслятор Си и компоновщики, и эти трое исполняются в разных подсистемах. Было неприятно, что надо было с командной строки прописывать поддержку linux32 после каждой перезагрузки. WSL2 не видел, можно ли там так же туда-сюда гулять, не знаю.
                        0
                        Короче. WSL2, как по мне, это в своём роде шаг назад, по сравнению с WSL1 Первая более интегрирована, с остальной системой, чем вторая.
                          0
                          Причём, вроде бы WSL не столько ради линукса затевалась, сколько ради Андроида. Не получилось, выкатили чисто Линукс. И в WSL 2 Андроида всё так же нет.
                          +1
                          На wsl2 запуск .exe вполне себе работает. И например explorer.exe. откроет текущий каталог в винде, если это /mnt/ — все как обычно откроется а если нет — откроется по «сети» что-то вроде \\wsl$\Ubuntu\home\vikarti
                          Из windows — можно просто вызвать bash.exe
                          А то что менее интегированно — ну так это и не скрывают ж. WSL1 такая же подсистема Windows как собственно и Win32 (реально правда многое из win32 — живет в ядре еще с NT4). Из-за этого и совместимость например с файрволлами и проблемы (с тем например что NT Native API все же больше рассчитан на те принципы по которым Win32 работает)
                          А WSL2 — хитрая виртуалка.
                            0
                            А WSL2 — хитрая виртуалка.

                            Чем же она хитрее обычных и привычных? Ну да, дистрибутивы там немного обрезанные и стартуют без полноценного systemd/sysvinit. А ещё что?
                              0
                              То как она взаимодействует с виндой. Кстати, обратите внимание, init там есть. Собственно ничего не мешает ему там быть. И почему сейчас там нет systemd вызывает очень большие вопросы. Это из презентации MS, когда вторую WSL ЕМНИП только выкатили… ну или собирались выкатить.
                                0
                                Интеграция.
                                Нет, можно конечно настроить и динамическую память и файловые шары по сети прокинуть в оба конца и проброс команд реализовать но тут все — работает. И у всех — одинаково. И (насколько я понимаю) для доступа к файлам не используется TCP/IP а 9P используется.
                                  0
                                  Да, именно 9P и используется. Причём не только для доступа к файлам, в обе стороны, но и для запуска bash / cmd.exe
                            +2
                            WSL2 да, это виртуалка. И почему там нет systemd для меня загадка, великая есть. А вот WSL1, это что-то похожее на вайн или даже точнее на слой совместимости с линукс во FreeBSD.
                    +3
                    У меня в башрц запуск докера засунут, из-за чего при запуске у меня просят пароль, т.к. там sudo. Судя по всему, эту штука будет команды от рута запускать. Вот и вполне причина, зачем это делали. WSL2 же не имеет полноценной init системы до сих пор.
                      +1
                      Вероятно в данный момент времени Вы решаете проблему с запуском либо через NOPASSWD в sudoers, что можно сделать в том числе для отдельных команд и автоматизировать парой команд, либо через echo «password» | sudo -S. И то и другое является вполне стандартным решением. Как и поддержка либо SysV либо systemd. Поддержку кстати реализуют сторонние разработчики не имея таких ресурсов как у MS — решения есть на GitHub. Но здесь выбрано нестандартное решение, которое с учетом возможностей Microsoft потенциально может породить новый конкурирующий стандарт.

                      Выше Вы написали что EEE здесь ни при чем. Но EEE — это ведь необязательно заговор менеджеров )) Та же ситуация может быть результатом игнорирования существующих стандартов простыми разработчиками, особенно если эти разработчики из большой компании с большими маркетинговыми возможностями. Менеджменту это может быть просто не важно или просто желательно (молчаливое одобрение), а разработчики работают по привычной схеме «все должно быть написано по своему, как всегда было в Microsoft».

                      В мире Linux уже безумная фрагментация и только недавно наметились шаги к стандартизации решения подобных задач. Почему загнулся Upstart? Потому что был проигнорирован разработчиками. Здесь же целью WSL являются именно разработчики. WSL создавался во многом для входа на рынок ML и еще чтобы разработчики продолжали на Windows сидеть и не смотрели наLево )) Если разработчики будут писать утилиты в стиле «инициализации» WSL больше шансов, что они не напишут в стиле Systemd как сделали бы работая в виртуалке или непосредственно в современных дистрибутивах Linux. И так кирпичик за кирпичиком и рождаются последние две буквы в EEE. Хотя намерения вероятно благие, как и большинство намерений Microsoft ))
                        0
                        Я не знаю, почему они не используют systemd, но подозреваю, что не от вредности и мифических ЕЕЕ. Все таки WSL интегрирован с виндой и мало ли что этот init процесс при запуске делает. Поднимает шары, пайпы какие-нибудь устанавливает с виндой, память шарит, еще чего. То, что требует специфичного для WSL кода.

                        Может объективно он нужен, а может это просто рудимент и от нехватки времени. WSL1 очевидно мог требовать свой init. WSL2 вполне мог бы и systemd использовать, но чтобы не ломать то, что уже работало, оставили свой init.

                        «все должно быть написано по своему, как всегда было в Microsoft».

                        Это было бы справедливо, будь это обычная сборка линукса. Здесь же нет «как всегда было». Такой вещи раньше никогда не было банально.
                          0
                          Линукс, в случае WSL2, находится в почти полностью изолированной песочнице — в виртуалке. И никаким каком не может повредить хостовой винде. Вот полная архитектура взаимодействия из презентации Microsoft.
                            0
                            это старая диаграмма тут не учтены фишка для реалтайма без хоста. Например запуск докера для виндовс напрямую через wsl2 режим.
                              0
                              А через 9P, так как это сделано для cmd.exe, думаете невозможно?
                            0
                            Да, в этом наверное есть смысл. Просто не хотелось бы чтобы они поспособствовали еще большей фрагментации. Точнее помешали текущему процессу стандартизации, когда появилась устоявшаяся система инициализации и уже поверх нее решения для запуска контейнеров. Текущие тенденции помогают и новым пользователям в Linux входить, и поддержку систем проще осуществлять. А у Microsoft достаточно ресурсов, внимания разработчиков и авторитета, чтобы вбить клин.

                            Ведь так можно продолжить мысль и для запуска периодических задач внутри WSL тоже изобрести что-то новое вместо cron или таймеров Systemd. Такое, что переплетено на уровне разделяемой памяти с планировщиком задач Windows и облаками Azure заодно )) Ведь раньше не было такого уникального решения как периодические задачи в WSL ))

                            Хотелось бы наоборот — чтобы разработчики написав решение для одной системы могли тиражировать его на родственные системы. Нельзя сказать что и на Linux за пределами скриптов bash/sh и Systemd это сейчас наблюдается, но со стороны пользователя вижу что есть движение в этом направлении и это радует.

                            Меня например как одновременно и пользователя Windows и Linux от использования WSL отталкивает именно эта перспектива собственных стандартов Microsoft. Когда то решил посмотреть что будет происходить в течение года-двух. Не начнет ли MS движение в сторону Extend своего несовместимого разлива. Если бы движение пошло в сторону стандартизации, то это была бы веская причина снизить использование виртуалок в пользу WSL, там где приходится работать с Windows. Но пока что паузу продляю ))

                            При необходимости всего того же самого позволяет добиться headless режим виртуалок с примонтированной с Windows-хоста файловой системой. И затем переносить решения на Linux-системы куда проще.
                        0

                        Не знаю на счёт первой версии, но так как WSL 2 — это виртуальная машина, то её запуск может быть из замороженного состояния, никакие запускаторы не сработают.

                        0
                        А что, systemd, например, в этом вашем их WSL уже отменили? Или смузихлёбы из MS про такие «сложности» не в курсе?
                        PS: Прочитал комменты… Ну это просто «война и немцы»
                        0
                        Наконец станет можно 32разрядные бинарники в binfmt_misc автоматом регистрировать на qemu-user
                          0
                          man binfmt.d и man systemd-binfmt в нормальных системах.
                          Вот у меня, например, файлик /etc/binfmt.d/regina-rexx.conf
                          # Regina Rexx tokenized script
                          :Regina_REXX_tokenized:M::Regina's Internal Format::/usr/local/lib/regina/tokenwrapper:
                          +3

                          А последние несколько минут работы после завершения последнего процесса чем занимается? Собирает и отправляет телеметрию?

                            0
                            WSL это конечно хорошо, но когда windows 10 сможет наконец-то запускать APK файлы?

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое