systemctl diras, ke systemd ne estas PID 1: kio sekvas?

Lanĉi systemctl start openvpn-client@office kaj ricevi mesaĝon, ke la sistemo ne estis ŝargita per systemd, aspektas kiel serva fiasko. Tute ne temas pri serva fiasko: la systemctl, kiun vi alvokis, ne trovas funkciantan administrilon por interparoli, do nenio pri OpenVPN estis ekzamenita. sudo ne kreas administrilon, kaj ankaŭ instalado de unit-dosiero ne kreas ĝin. La komando kaj la maŝino venas el du malsamaj mondoj, kaj la eraro estas la sola loko, kie tio montriĝis.

Komencu demandante, kiu procezo posedas PID 1 tie, kie la komando funkcias, ĉar tiu respondo decidas ĉu unitoj entute ekzistas.

La eraro nomas la medion, ne OpenVPN

systemctl estas kliento, ne administrilo. Ĝi konektiĝas al la sistema administrilo per ingo, kaj kiam mankas administrilo ĉe la alia fino, ĝi presas la mesaĝon, kiun homoj algluas en forumoj. ps -p 1 -o pid=,comm= montras, kio efektive funkcias kiel PID 1, kaj la respondo ofte estas ŝelo, init-ĉirkaŭaĵo aŭ la propra enirpunkto de la ujo. En tia situacio unit-dosiero povas esti tute valida kaj tamen neniam esti legata. Ripeti la komandon kiel root ŝanĝas nur la akreditaĵojn de la kliento.

Legu la tutan mesaĝon antaŭ la unua linio. Eraro de la administrilo mem, ekzemple mankanta unito aŭ malsukcesinta kondiĉo, signifas, ke vi atingis unu; ĉi tiu eraro signifas, ke vi ne atingis.

WSL: ŝalti systemd estas ŝanĝo de agordo

WSL akiris subtenon por systemd en postaj eldonoj, sed la funkcio estas ŝaltata por ĉiu distribuo aparte kaj nur tie, kie la instalita versio de WSL subtenas ĝin. wsl --version ĉe la Windows-flanko raportas, kion vi havas, kaj la /etc/wsl.conf de la distribuo enhavas [boot] sekcion kun systemd=true. Redaktu tiun dosieron sen forigi la jam ekzistantajn sekciojn, poste restartigu la WSL-kopion, por ke la ŝanĝo efiku. wsl --shutdown haltigas ĉiun funkciantan distribuon, do unue konservu vian laboron.

Post remalfermo, konfirmu la administrilon antaŭ ol tuŝi la uniton de OpenVPN: ps -p 1 -o comm= devus raporti systemd. Ŝalti systemd ne donas profilon, akreditaĵon nek kopian nomon, do la sekva eraro koncernos unu el tiuj, ne PID 1.

Ujoj lanĉas sian enirpunkton, ne unitojn

Normala ujo lanĉas tion, kion difinas ĝia enirpunkto aŭ komando, kaj ĝi ne estas maŝino ŝargita per systemd, kiom ajn da pakaĵoj vi instalas. Aldoni systemctl al la bildo donas al vi klienton sen io, al kio konektiĝi. Por Community OpenVPN la subtenata ŝablono kutime estas antaŭplana procezo, openvpn --config /path/to/client.conf, lanĉata de la enirpunkto kaj superrigardata de ekstere. Tiu posedanto zorgas pri lanĉo, signaloj kaj haltigo, kaj ĝi devus esti la sola afero, kiu administras la tunelon.

Neniam lanĉu interagan kopion apud enirpunkto, kiu jam administras tiun tunelon, ĉar du procezoj interbatalos pri la aparato kaj la vojoj. Minimuma init-procezo ene de la ujo kolektas infanojn kaj plusendadas signalojn; ĝi ne igas la bildon gastiganto kun unitoj.

Se deplojo vere bezonas systemd ene de ujo, ĝi bezonas bildon intence dizajnitan por tio, ne pliajn privilegiojn aldonatajn ĝis la systemctl ĉesos plendi.

Legu la sekvan eraron, kiam la administrilo ekzistas

Kiam vera administrilo lanĉas la servon, la utilaj eraroj komenciĝas. Malsukceso de aparata permeso, eraro de agorda analizo, mankanta akreditaĵo kaj neatingebla samtavolano estas kvar malsamaj problemoj, kiujn la mesaĝo pri PID 1 neniam testis. Legu ilin laŭ la ordo, en kiu la unito produktis ilin, uzante journalctl -u openvpn-client@office -n 50 ĉe systemd-gastiganto, aŭ lanĉante la klienton en la antaŭplano tie, kie mankas administrilo. Lanĉo en la antaŭplano estas ankaŭ la plej rapida maniero konfirmi, ke la profilo mem funkcias.

Tenadu la du mediojn aparte en viaj notoj: la gastiganto, kiu funkciigas la tunelon, kaj la loko, kie vi tajpas komandojn.