systemctl non è riuscito a connettersi al bus - docker ubuntu: contenitore 16.04

72

Sto cercando di utilizzare il systemctlcomando in un ubuntu:16.04contenitore finestra mobile. Sto eseguendo il seguente comando ...

systemctl status ssh

Tuttavia sto ricevendo l'errore ...

Failed to connect to bus: No such file or directory

Perché questo non funziona? Questo è legato a Ubuntu in esecuzione in un contenitore docker? Come posso systemctllavorare correttamente?

— Duncan Gravill
fonte

2

Usaservice ssh start

— Bidyut

50

Presumo che tu avvii il tuo contenitore docker con qualcosa del genere

docker run -t -i ubuntu:16.04 /bin/bash

Il problema ora è che il PID 1 del processo di inizializzazione /bin/bashnon è systemd. Confermare con ps aux.

In aggiunta a ciò che ti manca dbus con sarebbe il modo di comunicare. Ecco da dove proviene il tuo messaggio di errore. Ma poiché il tuo PID 1 non è systemd, non aiuterà l'installazione di dbus.

La cosa migliore sarebbe ripensare il modo in cui prevedi di utilizzare la finestra mobile. Non fare affidamento su systemd come gestore dei processi ma fare in modo che il contenitore della finestra mobile esegua l'applicazione desiderata in primo piano.

— user228505
fonte

Servizi come openssh-server sono configurati per accedere alla funzione syslog predefinita. Come posso ottenere i registri sshd senza fare affidamento su systemctl?

— Parth Shah,

@ParthShah, controlla la pagina man di sshd. Il mio ha le seguenti opzioni: Chiamandolo con -D puoi tenerlo in primo piano. con -e gli ordini di stampare direttamente i registri. questi possono poi essere ispezionati in modo docker con docker log.

— user228505

[FYI] stava ottenendo questo errore con il /sbin/initprocesso PID = 1. L'aggiunta --privileged=truecome suggerito da @sonjaya sonjaya di seguito ha risolto il problema.

— DimG

bella risposta !!

— Sachin Verma,

11

Altri hanno segnalato un problema simile. Avvia il terminale e digita:

$ env

Vedi una variabile d'ambiente come questa?

XDG_RUNTIME_DIR=/run/user/`id -u`

Dove id -uè racchiuso tra i backtick non le virgolette singole. Questa variabile viene reinterpretata in un numero solitamente 1000per utenti normali e 0per superutente (sudo).

Se la variabile di ambiente XDG_RUNTIME_DIRnon esiste, è necessario crearla. La discussione completa è nelle risposte di systemd del launchpad .

— WinEunuuchs2Unix
fonte

2

Ho provato questo senza successo. Poiché la mia istanza di Ubuntu 16.04 ha la forma di un contenitore docker e non ho impostato alcun utente con cui sto lavorando root, quindi ho usato la variabile XDG_RUNTIME_DIR=/run/root/0senza successo. Quindi ho controllato la cartella /rune ho scoperto che non esiste una sottocartella /run/root. Posso comunque ricevere un messaggio di errore più dettagliato? Ho dato un'occhiata systemctl --helpma non sono riuscito a vedere un modo per ottenere messaggi di errore dettagliati.

— Duncan Gravill,

1

Sto riscontrando lo stesso problema e anche questo non ha risolto il mio problema. Hai mai capito questo @DuncanGravill

— Roeland

3

@Roeland Sì. Ho fatto una domanda simile su SO che ha avuto una risposta più forte. Consiglio anche di guardare i tutorial su te stesso sul sito Web Docker. In quei video viene spiegato (leggermente vagamente) come di PID 1solito systemdviene sostituito in un contenitore Docker con il contenitore Entrypoint .

— Duncan Gravill,

Fantastico, grazie! Ne avevo bisogno per avviare / gestire un'unità utente da un'unità di sistema.

— Adrian Günter

6

Se ricevi questo errore nel sottosistema Windows per Linux (WSL), ho scoperto che Docker non è supportato. Ciò è dovuto alla mancanza di cgroups e altri prerequisiti.

— ijustlovemath
fonte

3

Prova questo:

docker run -ti -d --privileged=true images_docker  "/sbin/init"

o

docker run -ti -d --privileged=true images_docker

sarà lo stesso risultato.

Qui ottengo dal documento di Docker :

Per impostazione predefinita, i contenitori Docker sono "senza privilegi" e non possono, ad esempio, eseguire un demone Docker all'interno di un contenitore Docker. Questo perché di default un container non può accedere a nessun dispositivo, ma un container “privilegiato” ha accesso a tutti i dispositivi (vedere la documentazione sui dispositivi cgroups).

Quando l'operatore esegue docker run --privileged, Docker consentirà l'accesso a tutti i dispositivi sull'host e imposterà una configurazione in AppArmor o SELinux per consentire al contenitore quasi lo stesso accesso all'host dei processi in esecuzione all'esterno dei contenitori sull'host . Ulteriori informazioni sull'esecuzione con --privileged sono disponibili sul Blog Docker.

— sonjaya sonjaya
fonte

2

Potresti spiegare il tuo comando e la differenza alla domanda accettata ?

— Melebio

Benvenuto in AskUbuntu! Grazie per aver tentato di aiutare! Una rapida revisione della documentazione mi porta a credere che potresti aver commesso un errore o 2 in questo comando. Se saresti così gentile da modificarlo e spiegare cosa stai facendo e come risolve il problema, eseguimi il ping e tornerò e ti darò un voto!

— Elder Geek,

Quando dici images_docker, intendi ubuntu vanilla: 16.04? O qualcos'altro?

— Parth Shah,

2

Basta avviare il dbusservizio:

/etc/init.d/dbus start

— moovs
fonte

1

Potrebbe non essere in esecuzione systemd , che è l'implementazione predefinita di init su 16.04. Se hai eseguito l' aggiornamento da 14.04, molto probabilmente stai ancora eseguendo l' avvio , e il risultato dell'esecuzione del comando systemctl è l'output ottenuto.

Vedi la mia risposta su systemctl: comando non trovato per il server 16.04 .

— Hugh Buntu
fonte

Ma questo è un contenitore Ubuntu, che per impostazione predefinita non ha systemd e non avrebbe avviato.

— Stefan Lasiewski,

che cosa? ubuntu ha systemd di default

— knocte

Stefan: Credo che tu abbia ragione nel caso di Docker.

— Hugh Buntu,

knocte: il mio commento riguarda il caso dell'aggiornamento da 14.04 (Upstart) a 16.04 (systemd). Quando si esegue l'aggiornamento della versione, Upstart non viene sostituito con systemd per motivi comprensibili (come: non interrompere il sistema). In retrospettiva, mi rendo conto che il processo di aggiornamento della versione non sarebbe stato utilizzato in Docker. Vedi il link che ho chiamato. Vedo che numerose risposte e commenti non tengono conto del caso specifico di Docker e lo cercherò quando risponderò in futuro.

— Hugh Buntu,

0

All'interno del contenitore docker, penso che puoi aggiornare-rc.d se stai ancora lottando con systemd. Ho provato con update-rd.c e funziona.

— NEERAJ SWARNKAR
fonte

0

Stavo ottenendo lo stesso errore esatto e poi l'ho eseguito con successo sudo

sudo systemctl status ssh

— Saif
fonte

1

non dovresti averne bisogno sudo. Sembra una coincidenza. Puoi ripetere il test?

— Zanna,

1

@Zannasaif@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

— Saif

Perché -1? Ho appena pubblicato ciò che ha funzionato per me.

— Saif

il voto negativo non era mio ...

— Zanna,