10

Właśnie zainstalowałem Ubuntu 16.04 LTS i znalazłem to podczas uruchamiania

usr@server:~$ sudo service <servicename> restart
usr@server:~$

Usługa jest restartowana (widzę status za pomocą service <servicename> status), ale powłoka wraca bezpośrednio do wiersza poleceń bez oczekiwanego:

* Stopping <servicename>     [ OK ]
* Starting <servicename>     [ OK ]

— Eduardo Coria
źródło

Czy przejrzałeś dzienniki, aby sprawdzić, czy są jakieś informacje, które mogłyby pomóc w zdiagnozowaniu problemu? Powinno być w / var / log /

— Diego

2

Nie ma problemu z samą usługą. Zaskakuje mnie wiersz polecenia wracający bez wyjścia. Dzieje się tak z każdą usługą. Polecenie wykonuje to, co jest oczekiwane (uruchamia / zatrzymuje / restartuje usługę), ale nie ma danych wyjściowych

— Eduardo Coria

9

Nie powinieneś oczekiwać takich wyników.

Na początek Ubuntu nie zachowywał się w ten sposób we wcześniejszych wersjach. Ubuntu był nowatorskim systemem przez prawie dekadę, a zachowanie servicepolecenia na Ubuntu przez te wszystkie lata nie przypominało tego, czego się spodziewasz. Można zobaczyć zachowanie servicepolecenia na początku na obrazie w Jak uzyskać polecenie serwisowe do wydruku w 15.10? .

Odpowiedź jest prawie taka sama dla ciebie, jak i dla osób z Ubuntu w wersji 15.10 w zeszłym roku:

Używasz Ubuntu w wersji 16.10, systemowego systemu operacyjnego. Twoje zarządzanie usługami systemowymi nie jest już wykonywane przez upstart (lub jakiekolwiek narzędzie, które zrobiło to na jakimkolwiek systemie operacyjnym innym niż Ubuntu, jaki posiadałeś wcześniej). Jest to wykonywane przez systemd.

servicePolecenia mogą być takie same ... ale Debian / Ubuntu servicekomenda jest skryptem powłoki, który próbuje wykryć, czy auto-dorobkiewicz lub Systemd jest uruchomiony menedżer usługa systemowa i uruchom rzeczywistych rodzimych poleceń zarządzania usługami dla nowobogackich i Systemd. Wykonuje dwie całkiem różne ścieżki kodu dla upstart i dla systemd.

rodzime polecenia zarządzania usługami są dorobkiewicz initctl start, initctl stop, initctl statusi tak dalej. Te wiadomości są drukowane w miarę ich przesyłania.

rodzime polecenia zarządzania usługami Systemd są systemctl start, systemctl stop, systemctl statusi tak dalej. Te nie drukują danych wyjściowych podczas działania.

Dalsza lektura

— JdeBP
źródło

1

„Nie powinieneś oczekiwać takich wyników”. nie jest doskonałym miejscem na rozpoczęcie odpowiedzi. Mówisz w zasadzie: „Twoja opinia jest błędna”. Myślę, że to, co chciałeś powiedzieć, to „to nie jest możliwe z systemd”. W dniach upstartowych wyjście Ubuntu DID ... jest pytaniem „Jak uzyskać polecenie serwisowe, aby wydrukowało wyjście w 15.10”. Przed 15.10 Ubuntu używał upstart, a upstart (jak sysvinit) był gadatliwy. Więc proszę, nie mów: „Tak było przez dekadę”. Nie ma Zmieniło się to w 15.10. Systemd nie jest gadatliwy i to było bardzo irytujące, odkąd dystrybucje zaczęły go wdrażać.

— bobpaul,

Pytający dość wyraźnie powiedział, czego oczekiwał xe, a wyjściowy efekt wyjściowy nie przypomina tego. Jesteś zdezorientowany lub nie przeczytałeś pytania.

— JdeBP

0

W rzeczywistości nie potrzebujesz wyjścia OK. Brak danych wyjściowych oznacza OK. Gdy usługa nie uruchamia się poprawnie, Ubuntu pokazuje coś takiego:

Zadanie dla usługi php5.6-fpm.service nie powiodło się, ponieważ proces kontroli zakończył się z kodem błędu. Zobacz „status systeml php5.6-fpm.service” i „journalctl -xe”, aby uzyskać szczegółowe informacje.

W moim przypadku ten przykład był błędną konfiguracją na moim php-fpm.conf, która uniemożliwiła uruchomienie usługi. Po wykonaniu instrukcji posortowałem, co spowodowało błąd.

— Filipe Marques
źródło

Brak danych wyjściowych polecenia uruchomienia / zatrzymania / ponownego uruchomienia usługi

Nie powinieneś oczekiwać takich wyników.

Dalsza lektura