ExecStart nėra shell: VPN pagalbinio įrenginio taisymas

Nukopijuokite veikiančią komandų eilutę į ExecStart, įkelkite iš naujo, ir įrenginys sugenda arba tyliai baigia darbą, nes argumentai traktuojami kaip failų pavadinimai. systemd niekas nesugedę. ExecStart yra argumentų sąrašas, o ne shell, todėl konvejeriai, peradresavimas ir sąlygos praranda prasmę tą akimirką, kai palieka jūsų terminalą. Nuspręskite, kur turi būti shell, tada parašykite įrenginį, kuris tiksliai pasako, kas turi būti vykdoma.

Kodėl konvejeris ExecStart neturi jokio poveikio

Kai komanda įrašoma terminale, shell pirmiausia ją išanalizuoja. Jis sudaro konvejerį, atidaro failus peradresavimui ir išskleidžia kintamuosius prieš pradedant bet kuriai programai. systemd nieko to nedaro: jis padalija ExecStart pagal savo taisykles ir vykdo gautą programą su tais argumentais. Todėl > atkeliauja kaip pažodinis argumentas, o | perduodamas programai, o ne sujungia du procesus. Įrenginys nesielgia neteisingai; sintaksė reiškė ką kita.

Tai sąmoninga, o ne aplaidu, nes nuspėjamas argumentų apdorojimas daro įrenginius audituojamus. Tai nustebina tik tuos, kurie mano, kad shell yra.

Parašykite įrenginį, kuris tiksliai pasako, kas vykdoma

Pradėkite nuo mažo įrenginio, kurio paskirtis matoma žurnale, kad analizės problemos liktų atskirai nuo tunelio problemų. Šis tik praneša dvejetainės bylos versiją.

[Unit]
Description=Report the installed OpenVPN version

[Service]
Type=oneshot
ExecStart=/usr/sbin/openvpn --version
StandardOutput=journal
StandardError=journal

Kelias yra vietos žymeklis, todėl pakeiskite jį iš tikrųjų įdiegtu dvejetainiu failu. Type=oneshot tinka komandai, kuri vykdoma iki pabaigos, o žurnalo nustatymai padeda jos išvestį ten, kur galite perskaityti be terminalo. Sąmoningai nėra diegimo skyriaus, todėl įrenginys iškviečiamas rankiniu būdu, o ne įjungiamas paleidžiant. Patikrinkite failą prieš jį paleisdami, nes rašybos klaida direktyvos pavadinime sugenda kitaip nei klaida kelyje.

systemd-analyze verify /etc/systemd/system/openvpn-version.service
systemctl start openvpn-version.service

Laikykite shell logiką scenarijuje

Kai pagalbininkui tikrai reikia sąlyginės logikos, įdėkite tą logiką į scenarijų ir iškvieskite jį aiškiai. Scenarijui reikia interpretatoriaus eilutės, vykdymo leidimo ir išėjimo kodų, kuriuos paslauga gali pranešti. /bin/sh -c paleidimas su kabutėse esančia komanda veikia, bet jis paslepia kabučių taisykles įrenginio viduje ir apsunkina peržiūrą. Pavadintą scenarijų galima išbandyti rankiniu būdu ir vėliau pakeisti neredaguojant įrenginio. Nepasikliaukite interaktyvaus naudotojo shell profiliu, nes paslauga prasideda su savo aplinka.

Nustatykite WorkingDirectory, kai santykiniai keliai svarbūs, ir perduokite aplinką per palaikomas įrenginio direktyvas, o ne eksportuokite ją terminale. Paslaptys priklauso apsaugotiems failams arba prisijungimo duomenims, o ne argumentų sąrašams, kuriuos žurnalas gali įrašyti.

Patikrinkite įrenginį, kuris iš tikrųjų egzistuoja

Drop-in failai keičia elgseną neliesdami failo, kurį prisimenate redagavę. Perskaitykite, ką įkėlė tvarkyklė ir ką pranešė paskutinis paleidimas.

systemctl cat vpn-helper.service
journalctl -u vpn-helper.service -n 20 --no-pager

Įrenginio išrašas apima drop-in failus įkėlimo tvarka, ir būtent iš ten dažniausiai ateina netikėtas ExecStart. Po bet kokio pakeitimo iš naujo įkelkite tvarkyklę ir patvirtinkite, kad nauja apibrėžtis yra tai, ką spausdina systemctl cat. Žurnalas rodo tikslią komandų eilutę ir išėjimo būseną, o tai atskiria argumentų problemą nuo trūkstamo dvejetainio failo ar teisių klaidos. Tada nuspręskite, ar pagalbininkas priklauso esamam VPN gyvavimo ciklui, ar turi likti rankine diagnostika, nes antras foninis tunelio procesas sukuria konkuruojantį savininką.

Įrenginys, kuris pagal prašymą išspausdina teisingą išvestį, yra geras pirmas etapas. Tai dar ne tunelis, ir jis neturėtų apsimesti juo esąs.