Próbuję użyć systemctlpolecenia w ubuntu:16.04kontenerze dokowanym. Korzystam z następującego polecenia ...
systemctl status ssh
Jednak pojawia się błąd ...
Failed to connect to bus: No such file or directory
Dlaczego to nie działa? Czy ma to związek z uruchomieniem Ubuntu w kontenerze dokowanym? Jak mogę systemctlprawidłowo działać?
Odpowiedzi:
Zakładam, że zaczynasz swój kontener dokerów czymś takim
docker run -t -i ubuntu:16.04 /bin/bash
Problem polega teraz na tym, że proces inicjacji PID 1 /bin/bashnie jest systemowy. Potwierdź za pomocą ps aux.
Oprócz tego brakuje ci dbus, który byłby sposobem na komunikację. Stąd pochodzi komunikat o błędzie. Ale ponieważ twój PID 1 nie jest systemowy, nie pomoże zainstalować dbus.
Najlepiej byłoby przemyśleć sposób, w jaki planujesz używać dokera. Nie polegaj na systemd jako menedżerze procesów, ale pozwól kontenerowi dokera uruchomić żądaną aplikację na pierwszym planie.
docker log.
/sbin/initponieważ był to proces PID = 1. Dodanie --privileged=truezgodnie z sugestią @sonjaya sonjaya poniżej rozwiązało problem.
Inni zgłosili podobny problem. Uruchom terminal i wpisz:
$ env
Czy widzisz taką zmienną środowiskową?
XDG_RUNTIME_DIR=/run/user/`id -u`
Gdzie id -ujest ujęte w backtyki, a nie pojedyncze cytaty. Ta zmienna jest ponownie interpretowana na liczbę zwykle 1000dla zwykłych użytkowników i 0superużytkowników (sudo).
Jeśli zmienna środowiskowa XDG_RUNTIME_DIRnie istnieje, musisz ją utworzyć. Pełna dyskusja znajduje się w odpowiedziach systemowych startera .
root, więc użyłem zmiennej XDG_RUNTIME_DIR=/run/root/0bez powodzenia. Następnie sprawdziłem folder /runi stwierdziłem, że nie ma podfolderu /run/root. Czy w każdym razie mogę uzyskać bardziej szczegółowy komunikat o błędzie? Spojrzałem na, systemctl --helpale nie widziałem sposobu na uzyskanie szczegółowych komunikatów o błędach.
PID 1zwykle systemdzastępuje się go w kontenerze Docker z punktem wejścia kontenera .
Jeśli pojawia się ten błąd w podsystemie Windows dla systemu Linux (WSL), stwierdziłem, że jest to spowodowane tym, że Docker nie jest obsługiwany. Wynika to z braku grup i innych wymagań wstępnych.
Spróbuj tego:
docker run -ti -d --privileged=true images_docker "/sbin/init"
lub
docker run -ti -d --privileged=true images_docker
będzie taki sam wynik.
Oto dokument Dockera :
Domyślnie kontenery Docker są „nieuprzywilejowane” i nie mogą na przykład uruchomić demona Docker wewnątrz kontenera Docker. Jest tak, ponieważ domyślnie kontener nie ma dostępu do żadnych urządzeń, ale kontener „uprzywilejowany” ma dostęp do wszystkich urządzeń (patrz dokumentacja urządzeń cgroups).
Gdy operator uruchomi okno dokowane - uprzywilejowane, Docker umożliwi dostęp do wszystkich urządzeń na hoście, a także ustawi konfigurację w AppArmor lub SELinux, aby umożliwić kontenerowi prawie taki sam dostęp do hosta, jak procesy działające poza kontenerami na hoście . Dodatkowe informacje na temat uruchamiania z --privileged są dostępne na blogu Docker.
Być może nie działa systemd , co jest domyślną implementacją init 16.04. W przypadku uaktualnienia z 14.04, jesteś najprawdopodobniej nadal działa dorobkiewicz , a wynik uruchamiając systemctl polecenia jest wyjście masz.
Zobacz moją odpowiedź na stronie systemctl: komenda nie znaleziono serwera 16.04 więcej.
Wewnątrz kontenera dokerów, myślę, że możesz zaktualizować-rc.d, jeśli nadal masz problemy z systemd. Próbowałem z update-rd.c i działa.
Otrzymałem dokładnie ten sam błąd, a następnie pomyślnie go uruchomiłem sudo
sudo systemctl status ssh
sudo. Wygląda na zbieg okoliczności. Czy możesz powtórzyć test?
saif@sr-server:~$ systemctl status ssh Failed to connect to bus: No such file or directory saif@sr-server:~$ sudo systemctl status ssh [sudo] password for saif: ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-01-19 23:38:14 PKT; 4min 4s ago Main PID: 18222 (sshd) Tasks: 15 Memory: 32.7M CPU: 488ms
service ssh start