VPN pakalpojums neizdodas pie EXEC: salīdziniet unit, bināro failu un sudoers
Neizdošanās EXEC solī nozīmē, ka systemd nevarēja palaist bināro failu. Pirms kaut ko mainīt salīdziniet unit ceļu, instalēto ceļu un sudoers atļauju.
Vakar tunelis strādāja, un šorīt unit ir miris, žurnālā ir Failed at step EXEC spawning /usr/local/bin/vpnclient. Akreditācijas dati, maršruti un konts šajā teikumā nekad neparādās. systemd atrisināja ExecStart uz ceļu, lūdza kodolu to izpildīt, un kodols atteicās, visbiežāk tāpēc, ka šajā ceļā nekas neeksistē vai fails nav izpildāms. Uzskatiet kļūdu par faila un argv problēmu, līdz analizētā komanda pierāda pretējo.
Kāpēc EXEC neizdodas pirms autentifikācijas sākuma
systemd neizpilda ExecStart caur čaulu. Tas veic fork, no rindas izveido argumentu vektoru un izsauc execve pirmajam elementam. Ja šis izsaukums neizdodas, pakalpojums nekad nesasniedz paša VPN klienta kodu, tāpēc profila rediģēšana vai akreditācijas datu pārbaude nepalīdzēs.
Statusa kods atdala šo saimi no parastām avarēm. Unit, kas beidzas ar status=203/EXEC, nekad nav palaidis procesu; unit, kas startē un pēc tam beidzas ar status=1 varēja neizdoties autentifikācijā, DNS vai maršrutēšanā. Lasiet kodu pirms klienta žurnāla, jo pirmajā gadījumā klienta žurnāls būs tukšs.
Ceļš žurnālā ir tas, ko izmantoja systemd, nevis obligāti tas, ko rediģējāt jūs. Drop-in faili un ģeneratora izvade var aizstāt piegādātāja failu, un novecojis daemon-reload atstāj veco rindu atmiņā. Tāpēc pirmā diagnostika ir pajautāt systemd, ko tas uzskata par komandu, nevis atvērt failu, kuru atceraties mainījis.
Trīs vietas, kur pierakstīts binārā faila ceļš
VPN klients, kas instalēts no izplatīšanas pakotnes, piegādātāja skripta un izlaiduma tarball, var nonākt trīs dažādos prefiksos. Unit, privilēģiju noteikums un instalētājs katrs pierakstīja vienu no šiem prefiksiem, un kļūda parādās, kad divi no trim nesakrīt.
| Record | Common value | How to read it |
|---|---|---|
| Unit or drop-in | /usr/local/bin/vpnclient | systemctl cat vpnclient.service |
| Installed binary | /usr/bin/vpnclient | command -v vpnclient, then ls -l the result |
| Sudoers grant | /opt/vpnclient/bin/vpnclient | sudo grep -r vpnclient /etc/sudoers.d/ |
Konkrēta neatbilstība izskatās šādi: piegādātāja skripts instalē uz /usr/local/bin, tarball tika izpakots zem /opt, un unit joprojām nosauc veco /usr/bin ceļu no iepriekšējās pakotnes. Eksistē tikai viens no šiem failiem, un reti tas ir fails, kas ir ExecStart.
Pirms mainīt jebkuru failu, izlemiet, kurš ceļš ir kanoniskais. Ja bināro failu pieder izplatīšanas pakotnei, kanoniskais ir pakotnes ceļš, un unit tam jāseko. Ja to pieder piegādātāja skriptam, tas pats noteikums attiecas uz piegādātāja prefiksu. Binārā faila kopēšana starp prefiksiem rada divas kopijas, kas nākamajā atjauninājumā izšķirsies.
Kad komanda pēdiņās kļūst par faila nosaukumu
Otrs kļūdas veids slēpjas aiz tās pašas žurnāla rindas. Kāds ieraksta to unit un gaida, ka klients pieslēgsies palaišanas laikā:
ExecStart=/usr/bin/"vpnclient connect office"systemd sadala vērtību vārdos, tāpēc pirmais vārds kļūst /usr/bin/vpnclient connect office, bet pēdiņas tiek noņemtas kā grupēšanas sintakse. Pēc tam kodols meklē failu, kura nosaukumā ir atstarpes, un tāda nav. Kļūda ir identiska trūkstošam binārajam failam, lai gan fails ir instalēts.
Atbalstītā forma ir īsts izpildāmais fails, kam seko atsevišķi argumenti, piemēram, ExecStart=/usr/bin/vpnclient connect office. Ja darbplūsmai tiešām vajag cauruli vai ķēdi, ievietojiet to skriptā un izsauciet skriptu, jo ExecStart nav &&, nav cauruļu un nav glob paplašināšanas.
Labojiet unit, nevis failu sistēmu
Kārdinošais labojums ir simboliska saite no gaidītā ceļa uz īsto bināro failu. Tā strādā, līdz pakotne tiek atjaunināta un saite norāda uz dzēstu failu, vai līdz SELinux etiķete vairs neatbilst mērķim. Labāk rediģējiet unit ar drop-in, lai piegādātāja fails paliktu neskarts un atjauninājumi paliktu paredzami.
Privilēģiju noteikumam jāatbilst tam pašam ceļam un tām pašām apakškomandām. sudoers ieraksts /usr/local/bin/vpnclient nepiešķir tiesības uz /usr/bin/vpnclient, un ieraksts, kas atļauj jebkuru argumentu, ļauj jebkuram lokālam procesam pārkonfigurēt vai apturēt tuneli. Dodiet abus darbības vārdus, kas nepieciešami unit, un turiet demontāžu ārpus tā, ja pakalpojuma apturēšana jau aizver saskarni.
Šeit salīdzinājums atmaksājas: unit, pakotņu datubāzei un sudoers jānosauc viens ceļš. Kad tā notiek, EXEC kļūda pazūd bez pārstartēšanas un bez binārā faila kopijas trešajā vietā.
Pierādiet analizēto komandu pirms pārstartēšanas
sudo systemctl daemon-reload
sudo systemctl cat vpnclient.service
systemctl show -p ExecStart vpnclient.service
systemd-analyze verify /etc/systemd/system/vpnclient.service
sudo systemctl restart vpnclient.service
systemctl status vpnclient.service --no-pagersystemctl show ir izšķirošā izvade, jo tā izdrukā argv, ko systemd patiešām analizēja, ieskaitot jebkuru drop-in. systemd-analyze verify pirms pārstartēšanas noķer trūkstošu vai neizpildāmu ceļu, un statusa komanda pēc pārstartēšanas pasaka, vai process tagad eksistē.
Ja unit startē un pēc tam neizdodas, jūs esat atstājis EXEC saimi un nonācis paša klienta kļūdu apstrādē. Žurnālā meklējiet klienta ziņojumu, nevis vēl vienu execve neizdošanos. Turiet unit diff un sudoers diff kopā izmaiņu ierakstā, lai nākamais atjauninājums klusi neatgrieztu sadalīto ceļu.