Better Windows ServicesWiersz poleceń
Każda komenda, każdy przełącznik i każdy kod wyjścia programu bws w wersji 0.1.0. Źródłem prawdy jest bws --help i jest dłuższy - ta strona to ta sama powierzchnia, rozłożona tak, żeby dało się ją czytać. Program mówi po angielsku, więc komendy, przełączniki i jego własne komunikaty są tu w oryginale.
Komendy
Osiem czasowników. snapshot jest rzeczownikiem i wymaga słowa po sobie.
bws list [--query TEXT] [--signatures] [--memory] [--required-by] [--follow-network] [--json] [--timing]
bws show NAME [--full] [--follow-network] [--json] [--timing]
bws stop|start|restart NAME [--dry-run] [--dependents] [--timeout SECONDS] [--json] [--timing]
bws kill NAME [--force] [--restart] [--dry-run] [--dependents] [--timeout SECONDS] [--json] [--timing]
bws start-type NAME automatic|manual|disabled [--dry-run] [--json] [--timing]
bws snapshot create [FILE] [--note TEXT] [--follow-network] [--force] [--json] [--timing]
bws snapshot diff EARLIER LATER [--exit-code] [--json] [--timing]
bws snapshot diff EARLIER --live [--exit-code] [--json] [--timing]
bws --help
bws --versionLiterówka w czasowniku dostaje podpowiedź, o który prawdopodobnie chodziło, a przebieg kończy się kodem 2, zamiast zrobić coś zbliżonego do tego, o co prosiłeś.
$ bws lst
There is no command lst. There is: list, show, stop, start, restart, start-type, kill, snapshot.Co robi każdy czasownik
list i show
list to cała maszyna, zawężona przez --query. show to jeden wpis ze wszystkim, co o nim wiadomo - podpis, przywileje, deskryptor bezpieczeństwa i pamięć, wszystko czytane za każdym razem, bo na jednym wpisie kosztuje to około sześćdziesięciu milisekund, a na całej maszynie sekundę. Pola naprawdę puste są pomijane, chyba że podasz --full. Pole, którego nie dało się odczytać, drukuje się i tak, bo pominięcie go wyglądałoby jak odpowiedź.
stop, start i restart
Każdy buduje plan i go wykonuje. --dry-run drukuje plan i nie zmienia niczego, --dependents wstawia do niego usługi, które przestaną działać, jako osobne kroki, a --timeout mówi, jak długo czekać na jeden krok. Sterowniki są odmawiane, a nie próbowane, bo zatrzymanie sterownika jądra często nie jest odwracalne bez restartu.
kill - dla usługi, która nie chce się zatrzymać
Prosi usługę o zatrzymanie i kończy stojący za nią proces tylko wtedy, gdy to nie zadziała, więc wpis, który zatrzymuje się sam, nigdy nie jest ubijany. Zakończenie procesu zabiera ze sobą każdą inną usługę żyjącą w tym procesie, niezależnie od tego, czy zatrzymała się wcześniej - a podgląd wymienia je po nazwie i podaje numer procesu. --force pomija uprzejmy krok, więc podgląd pokazuje jeden krok zamiast dwóch. --restart podnosi wszystko z powrotem.
Windows nazywa ten pomysł inaczej. --force w Stop-Service znaczy „nawet jeśli coś od tego zależy", czyli to, co tutaj robi --dependents. Dlatego jest to osobny czasownik, a nie przełącznik przy stop.
start-type - ustawienie, nie ruch
Mówi, co menedżer zrobi z wpisem przy następnym starcie systemu, i nie przesuwa niczego: wpis działający dalej działa, zatrzymany dalej stoi. Nad disabled warto się zatrzymać, bo to znaczy, że menedżer nie uruchomi wpisu w ogóle - także na żądanie, dla czegoś innego, co go potrzebuje.
snapshot create i snapshot diff
create zawsze czyta podpisy i skróty, bo snapshot jest trzymany i porównywany później, a taki bez nich porównywałby się z takim z nimi tak, jakby maszyna się zmieniła. diff mówi, co się zmieniło w drodze z pierwszego pliku do drugiego, albo z pliku do tej maszyny przy --live. Strona o snapshotach niesie format i uzasadnienie.
Przełączniki
Jest ich 16. Trzecia kolumna to czasowniki, do których każdy należy - przełącznik podany czasownikowi, który nie ma z niego pożytku, jest błędem z tą listą w treści, a nie flagą po cichu zignorowaną.
| Przełącznik | Co robi | Gdzie działa |
|---|---|---|
--query | Zawęża listę językiem zapytań. | list |
--signatures | Czyta, kto podpisał każdy plik i czy Windows temu podpisowi ufa. Kilka sekund na całej maszynie, więc jest wyłączone, dopóki nie poprosisz - a zapytanie o podpisy włącza to samo. | list |
--memory | Czyta, ile pamięci zajmuje proces każdego działającego wpisu. Domyślnie wyłączone, bo to pomiar, a nie ustawienie: sekundę później jest inny. | list |
--required-by | Czyta, które wpisy przestaną działać po zatrzymaniu tego - pytając Windows wprost, zamiast wyliczać to z deklaracji. Jedno wywołanie na wpis, więc wyłączone, dopóki nie poprosisz. show i snapshot create czytają to zawsze. | list |
--follow-network | Pozwala zajrzeć pod ścieżkę uruchomienia leżącą na innej maszynie. Domyślnie wyłączone dla bezpieczeństwa: jeden nieosiągalny udział kosztuje dwadzieścia jeden sekund, a połączenie uwierzytelnia się jako ten, kto uruchomił program. | list, show, snapshot create |
--force | Przy kill kończy proces od razu, bez uprzejmego pytania - podgląd pokazuje wtedy jeden krok zamiast dwóch. Przy snapshot create nadpisuje istniejący plik. | snapshot create, kill |
--restart | Przy kill podnosi wpis z powrotem, gdy proces zniknie, razem ze wszystkim, co ten proces dzieliło. | kill |
--full | Przy show drukuje także pola, które są naprawdę puste. Pole, którego nie dało się odczytać, drukuje się i tak. | show |
--json | Ten sam dokument, czytelny dla maszyny, na wyjściu standardowym. | list, show, stop, start, restart, start-type, snapshot create, snapshot diff, kill |
--note | Po co snapshot został zrobiony - zapisane w środku pliku. | snapshot create |
--exit-code | Kończy kodem 5, gdy cokolwiek się różni. Domyślnie wyłączone, żeby skrypt, który chce tylko zobaczyć różnice, nie wywracał się na tym, że je znalazł. | snapshot diff |
--live | Porównuje plik z tą maszyną w jej obecnym stanie, zamiast z drugim plikiem. | snapshot diff |
--timing | Ile trwała każda część odczytu, na wyjściu błędów. | list, show, stop, start, restart, start-type, snapshot create, snapshot diff, kill |
--dry-run | Drukuje plan i nie zmienia niczego. To ten sam plan, który wykonuje się przy wykonaniu - nie ma drugiej ścieżki kodu dla wersji prawdziwej. | stop, start, restart, start-type, kill |
--dependents | Wstawia do planu, jako osobne kroki, usługi, które przestaną działać. | stop, restart, kill |
--timeout | Jak długo czekać, aż jeden krok osiągnie stan, o który poprosił, licząc od chwili przyjęcia żądania przez menedżera. Sześćdziesiąt sekund, o ile nie powiesz inaczej. Wyczerpanie tego czasu jest końcem patrzenia, a nie porażką - raport mówi, w jakim stanie wpis został zostawiony. | stop, start, restart, kill |
Kody wyjścia
6 zakończeń, a każde z nich jest dla skryptu czymś innym. Dane idą na wyjście standardowe, a cała reszta na wyjście błędów, więc bws list --json | jq działa, a ostrzeżenie nigdy nie ląduje w JSON-ie.
| Kod | Znaczenie |
|---|---|
0 | Zrobione, i wszystko dotarło tam, gdzie miało dotrzeć. |
1 | Narzędzie zawiodło - nie zrobiło tego, o co poproszono, z powodu dotyczącego samego narzędzia, a nie planu. |
2 | Wiersz poleceń był zły. Przy literówce w komendzie program podpowiada tę, o którą prawdopodobnie chodziło. |
3 | Plan był dobry, wykonał się, a coś w nim nie dotarło tam, gdzie miało - menedżer odmówił albo sesja nie miała do tego praw. |
4 | Ktoś zatrzymał przebieg ręcznie. Niezerowy nawet wtedy, gdy każdy krok i tak dotarł, żeby skrypt nadrzędny nie potraktował przerwanego przebiegu jako czystego. |
5 | Porównanie wykonało się i znalazło różnice. Tylko z --exit-code, bo dryf jest tym, czego to narzędzie szuka, a znalezienie go nie jest porażką. |
Ctrl+C ma trzy poziomy, a każdy mówi, ile kosztuje następny. Pierwszy przestaje iść naprzód i nadal oddaje to, co zabrał, drugi zostawia rzeczy jak są i nadal drukuje raport, trzeci kończy proces. Przebieg zatrzymany ręcznie kończy się kodem 4 nawet wtedy, gdy każdy krok i tak dotarł.
W zadaniu harmonogramu
Kształt, pod który ten program powstał: zamroź maszynę, gdy wiadomo, że jest dobra, a potem co noc pytaj, czy nadal jest.
# w dniu, w którym maszyna wchodzi do pracy
bws snapshot create C:\baselines\web01.json --note "after the build"
# co noc, z zadania harmonogramu
bws snapshot diff C:\baselines\web01.json --live --exit-code --json > C:\logs\drift.json
# 0 - nic się nie różni
# 5 - coś się różni, a drift.json mówi co
# 3 - wykonało się i nie wszystko dało się odczytać, więc odpowiedź jest częściowaOkno jest drugą połową tego samego silnika: niesie je BetterWindowsServices-win-x64.zip, a strona pobierania mówi, co jest w którym archiwum.
Jedyny argument okna
BetterWindowsServices.exe zna jeden: --catalogue otwiera arkusz dla programisty, pokazujący każdy komponent okna w każdym stanie, i nie czyta niczego z Twojej maszyny.