ExecStart bir shell değil: VPN yardımcı birimini onarmak

Çalışan bir komut satırını ExecStart'a kopyalayın, yeniden yükleyin; birim argümanları dosya adı saydığı için başarısız olur ya da sessizce çıkar. systemd'de bozulan bir şey yok. ExecStart bir argüman listesidir, shell değildir; bu yüzden borular, yönlendirme ve koşullar terminalinizden çıktıkları anda anlamlarını yitirir. Shell'in nereye ait olduğuna karar verin, sonra tam olarak neyin çalıştırılacağını söyleyen bir birim yazın.

ExecStart'taki boru hattı neden hiçbir şey yapmaz

Bir komut terminale yazıldığında shell onu önce ayrıştırır. Bir boru hattı kurar, yönlendirme için dosyalar açar ve herhangi bir program başlamadan önce değişkenleri genişletir. systemd bunların hiçbirini yapmaz: ExecStart'ı kendi kurallarına göre böler ve ortaya çıkan programı o argümanlarla çalıştırır. Bu yüzden > düz bir argüman olarak gelir ve | iki süreci birbirine bağlamak yerine programa verilir. Birim yanlış davranmıyor; sözdizimi başka bir şey demek istiyordu.

Bu dikkatsizlik değil bilinçli bir tercihtir, çünkü argümanların öngörülebilir işlenmesi birimleri denetlenebilir kılar. Bu yalnızca bir shell olduğunu varsayanları şaşırtır.

Tam olarak neyin çalıştığını söyleyen bir birim yazın

Amacı günlükte görünen küçük bir birimle başlayın; böylece ayrıştırma sorunları tünel sorunlarından ayrı kalır. Bu birim yalnızca bir ikili dosyanın sürümünü bildirir.

[Unit]
Description=Report the installed OpenVPN version

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

Yol bir yer tutucudur, bu yüzden onu gerçekten kurulu olan ikili dosyayla değiştirin. Type=oneshot sonuna kadar çalışan bir komuta uygundur ve günlük ayarları çıktısını terminal olmadan okuyabileceğiniz yere koyar. Bilinçli olarak kurulum bölümü yoktur, bu yüzden birim açılışta etkinleştirilmek yerine elle çağrılır. Başlatmadan önce dosyayı doğrulayın, çünkü bir yönerge adındaki yazım hatası yoldaki hatadan farklı biçimde başarısız olur.

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

Shell mantığını bir betikte tutun

Bir yardımcı gerçekten koşullu mantığa ihtiyaç duyduğunda, o mantığı bir betiğe koyun ve açıkça çağırın. Betiğin bir yorumlayıcı satırına, çalıştırma iznine ve hizmetin bildirebileceği çıkış kodlarına ihtiyacı vardır. /bin/sh -c tırnak içindeki bir komutla başlatmak işe yarar, ama tırnak kurallarını birimin içinde saklar ve incelemeyi zorlaştırır. Adlandırılmış bir betik elle test edilebilir ve sonra birimi düzenlemeden değiştirilebilir. Etkileşimli kullanıcının shell profilini kullanmayın, çünkü bir hizmet kendi ortamıyla başlar.

Göreli yollar önemli olduğunda WorkingDirectory ayarlayın ve ortamı terminalde dışa aktarmak yerine birimin desteklediği yönergelerle geçirin. Sırlar korumalı dosyalara ya da kimlik bilgilerine aittir, günlüğün kaydedebileceği argüman listelerine değil.

Gerçekten var olan birimi denetleyin

Drop-in dosyaları, düzenlediğinizi hatırladığınız dosyaya dokunmadan davranışı değiştirir. Yöneticinin ne yüklediğini ve son çalıştırmanın ne bildirdiğini okuyun.

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

Birim dökümü drop-in dosyalarını yükleme sırasına göre içerir ve beklenmedik bir ExecStart genellikle oradan gelir. Her değişiklikten sonra yöneticiyi yeniden yükleyin ve yeni tanımın systemctl cat tarafından basılan şey olduğunu doğrulayın. Günlük tam komut satırını ve çıkış durumunu gösterir, bu da argüman sorununu eksik bir ikili dosyadan ya da izin hatasından ayırır. Sonra yardımcının var olan VPN yaşam döngüsüne mi ait olduğuna yoksa elle yapılan bir tanılama olarak mı kalması gerektiğine karar verin, çünkü ikinci bir arka plan tünel süreci rakip bir sahip yaratır.

İstek üzerine doğru çıktıyı basan bir birim iyi bir ilk kilometre taşıdır. Henüz bir tünel değildir ve tünel gibi davranmamalıdır.