Kopjoni një rresht komande që funksionon në ExecStart, riringarkoni dhe njësia dështon ose del në heshtje, duke i trajtuar argumentet si emra skedarësh. Asgjë nuk është prishur në systemd. ExecStart është një listë argumentesh, jo një shell, prandaj tubat, ridrejtimi dhe kushtet humbin kuptimin në momentin që lënë terminalin tuaj. Vendosni ku i takon shell-it, pastaj shkruani një njësi që thotë saktësisht çfarë duhet ekzekutuar.

Pse tubacioni në ExecStart nuk bën asgjë

Kur një komandë shkruhet në një terminal, shell-i e analizon fillimisht. Ai ndërton një tubacion, hap skedarë për ridrejtim dhe zgjeron variablat përpara se të nisë çdo program. systemd nuk bën asgjë nga këto: e ndan ExecStart sipas rregullave të veta dhe ekzekuton programin që rezulton me ato argumente. Prandaj > vjen si argument fjalëpërfjalë, dhe një | i dorëzohet programit në vend që të lidhë dy procese. Njësia nuk sillet keq; sintaksa nënkuptonte diçka tjetër.

Kjo është e qëllimshme dhe jo e pakujdesshme, sepse trajtimi i parashikueshëm i argumenteve është ai që i bën njësitë të auditueshme. Kjo befasojnë vetëm ata që supozojnë se ka një shell.

Shkruani një njësi që thotë saktësisht çfarë ekzekutohet

Filloni me një njësi të vogël, qëllimi i së cilës duket në ditar, në mënyrë që problemet e analizimit të mbeten të ndara nga problemet e tunelit. Kjo raporton vetëm versionin e një binari.

[Unit]
Description=Report the installed OpenVPN version

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

Rruga është një vendmbajtëse, prandaj zëvendësojeni me binarin që është i instaluar në të vërtetë. Type=oneshot përshtatet me një komandë që ekzekutohet deri në fund, dhe cilësimet e ditarit e vendosin daljen e saj aty ku mund ta lexoni pa terminal. Nuk ka qëllimisht seksion instalimi, prandaj njësia thirret me dorë në vend që të aktivizohet në nisje. Verifikoni skedarin përpara se ta nisni, sepse një gabim shtypi në emrin e një direktive dështon ndryshe nga një gabim në rrugë.

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

Mbajini logjikën e shell-it në një skript

Kur një ndihmës ka vërtet nevojë për logjikë kushtëzuese, vendoseni atë logjikë në një skript dhe thirreni shprehimisht. Skripti ka nevojë për një rresht interpretuesi, leje ekzekutimi dhe kode daljeje që shërbimi mund të raportojë. Nisja e /bin/sh -c me një komandë midis thonjëzave funksionon, por fsheh rregullat e thonjëzave brenda një njësie dhe e vështirëson rishikimin. Një skript me emër mund të testohet me dorë dhe më vonë të zëvendësohet pa redaktuar njësinë. Mos u mbështetni në profilin e shell-it të përdoruesit ndërveprues, sepse një shërbim niset me mjedisin e vet.

Vendosni WorkingDirectory, kur rrugët relative kanë rëndësi, dhe kaloni mjedisin përmes direktivave të mbështetura të njësisë në vend që ta eksportoni në një terminal. Sekretet i përkasin skedarëve të mbrojtur ose kredencialeve, jo listave të argumenteve që ditari mund të regjistrojë.

Kontrolloni njësinë që ekziston vërtet

Skedarët drop-in ndryshojnë sjelljen pa prekur skedarin që ju kujtohet se keni redaktuar. Lexoni çfarë ngarkoi menaxheri dhe çfarë raportoi ekzekutimi i fundit.

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

Përmbledhja e njësisë përfshin skedarët drop-in sipas rendit të ngarkimit, dhe prej andej zakonisht vjen një ExecStart i papritur. Pas çdo ndryshimi, riringarkoni menaxherin dhe konfirmoni se përkufizimi i ri është ai që shtyp systemctl cat. Ditari tregon rreshtin e saktë të komandës dhe statusin e daljes, gjë që e ndan një problem argumentesh nga një binar që mungon ose një gabim lejeje. Pastaj vendosni nëse ndihmësi i përket ciklit të jetës së VPN-së ekzistuese ose duhet të mbetet një diagnostikim manual, sepse një proces i dytë tuneli në sfond krijon një pronar konkurrues.

Një njësi që shtyp daljen e duhur sipas kërkesës është një pikë e parë e mirë. Nuk është ende tunel dhe nuk duhet të pretendojë se është.

Artikuj të ngjashëm