systemctl pravi, da systemd ni PID 1: in kaj zdaj?

Ko systemctl start openvpn-client@office zaženete in prejmete sporočilo, da sistem ni bil zagnan s systemd, je videti kot okvara storitve. To sploh ni okvara storitve: systemctl, ki ste ga poklicali, ne najde delujočega upravitelja, s katerim bi se pogovarjal, zato glede OpenVPN ni bilo nič pregledano. sudo ne ustvari upravitelja, in nameščanje datoteke unit ga prav tako ne ustvari. Ukaz in stroj prihajata iz dveh različnih svetov, napaka pa je edino mesto, kjer se je to pokazalo.

Začnite z vprašanjem, kateri proces ima PID 1 tam, kjer se ukaz izvaja, ker ta odgovor odloči, ali datoteke unit sploh obstajajo.

Napaka poimenuje okolje, ne OpenVPN

systemctl je odjemalec, ne upravitelj. Poveže se s sistemskim upraviteljem prek vtičnice, in ko na drugi strani ni upravitelja, izpiše sporočilo, ki ga ljudje prilepijo na forume. ps -p 1 -o pid=,comm= pokaže, kaj v resnici teče kot PID 1, in odgovor je pogosto lupina, init ovoj ali lastna vstopna točka vsebnika. V taki situaciji je lahko datoteka unit povsem veljavna in vendar nikoli prebrana. Ponovitev ukaza kot root spremeni le poverilnice odjemalca.

Preberite celotno sporočilo pred prvo vrstico. Napaka samega upravitelja, na primer manjkajoča enota ali neuspešen pogoj, pomeni, da ste do njega prišli; ta napaka pomeni, da niste.

WSL: omogočanje systemd je sprememba konfiguracije

WSL je podporo za systemd dobil v poznejših izdajah, vendar se funkcija omogoči za vsako distribucijo posebej in le tam, kjer jo nameščena različica WSL podpira. wsl --version na strani Windows pokaže, kaj imate, in /etc/wsl.conf distribucije vsebuje [boot] razdelek z systemd=true. Uredite to datoteko, ne da bi odstranili že obstoječe razdelke, nato znova zaženite primerek WSL, da sprememba začne veljati. wsl --shutdown ustavi vsako delujočo distribucijo, zato najprej shranite delo.

Ko jo znova odprete, potrdite upravitelja, preden se dotaknete enote OpenVPN: ps -p 1 -o comm= bi moralo pokazati systemd. Omogočanje systemd ne prinese profila, poverilnic ali imena primerka, zato se bo naslednja napaka nanašala na eno od tega, ne na PID 1.

Vsebniki zaženejo svojo vstopno točko, ne enot

Običajen vsebnik zažene, kar določi njegova vstopna točka ali ukaz, in ni stroj, zagnan s systemd, ne glede na to, katere pakete namestite. Če sliki dodate systemctl, dobite odjemalca brez česa za povezavo. Pri Community OpenVPN je podprt vzorec običajno proces v ospredju, openvpn --config /path/to/client.conf, ki ga zažene vstopna točka in se nadzoruje od zunaj. Ta lastnik skrbi za zagon, signale in zaustavitev, in moral bi biti edina stvar, ki upravlja tunel.

Nikoli ne zaženite interaktivne kopije ob vstopni točki, ki že upravlja ta tunel, ker dva procesa se bosta prepirala zaradi naprave in poti. Minimalen init proces v vsebniku pobere otroke in posreduje signale; ne spremeni slike v gostitelja z enotami.

Če uvajanje res potrebuje systemd v vsebniku, potrebuje namensko zasnovano sliko, ne dodatnih privilegijev, ki jih dodajate, dokler se systemctl ne neha pritoževati.

Preberite naslednjo napako, ko upravitelj obstaja

Takoj ko pravi upravitelj zažene storitev, se začnejo koristne napake. Neuspeh dovoljenja za napravo, napaka pri razčlenjevanju konfiguracije, manjkajoče poverilnice in nedosegljiv partner so štirje različni problemi, ki jih sporočilo o PID 1 nikoli ni preizkusilo. Preberite jih v vrstnem redu, v katerem jih je ustvarila enota, z journalctl -u openvpn-client@office -n 50 na gostitelju systemd ali tako, da odjemalec zaženete v ospredju tam, kjer ni upravitelja. Zagon v ospredju je tudi najhitrejši način za potrditev, da sam profil deluje.

Obe okolji imejte v svojih zapiskih ločeni: gostitelja, ki poganja tunel, in mesto, kjer vnašate ukaze.