PID dosyası var, tünel yok: OpenVPN hiç çalıştı mı?

Başlatıcı, PID dosyası zaten var olduğu için OpenVPN'i başlatmayı reddettiğinde doğal okuma bir yerde bir tünelin çalıştığıdır. Bu okuma, herhangi bir şey silinmeden önce kontrol edilmeye değecek kadar sık yanlıştır. Çalışma zamanı dizinindeki bir dosya muhasebedir ve muhasebe, ardında süreç bırakmamış çökmelerden, yeniden başlatmalardan ve kesintiye uğramış kapanmalardan sağ çıkar. Durumu iki soru belirler: canlı bir süreç var mı ve o süreç bu örneğe mi ait.

Dosyayla değil, hizmetle başlayın

Ret genellikle OpenVPN'in kendisinden değil, bir başlatıcıdan gelir. Bir yolu okur, orada bir şey bulur ve yapılandırma ayrıştırılmadan önce durur. Yani ilk soru tünel hakkında değil, başlatıcının sözleşmesi hakkındadır.

İletiyi yazdıran birimi veya betiği okuyun ve üç şeye dikkat edin: denetlediği yol, bildirdiği hizmet türü ve dosyayı yazmaktan sorumlu olup olmadığı. Modern bir birim basit ya da bildirim denetimi kullanıp PID dosyasına hiç dokunmayabilir; eski bir init betiği ise kendi başına bir tane oluşturabilir. Bir denetimi bir modelden diğerine kopyalamak tam olarak bu tür bir ret üretir. Bir şeyi yorumlamadan önce hangi modelin kullanıldığını bulun.

Ancak o zaman soru bir örneğin gerçekten çalışıp çalışmadığına dönüşür.

Bu tanımlayıcının sizin örneğinize ait olup olmadığını denetleyin

Dosyadaki bir sayı, bir sayının yazıldığını kanıtlar. O tanımlayıcıya sahip bir sürecin şu anda var olduğunu kanıtlamaz ve sürecin sizin olduğunu da kesinlikle kanıtlamaz, çünkü tanımlayıcılar yeniden başlatmadan sonra yeniden kullanılır.

Sürecin başlama zamanını dosyanın zaman damgasıyla, çalıştırılabilir dosyayı birimin komutuyla ve hizmet üyeliğini birimin adıyla karşılaştırın. Üçünden herhangi birindeki uyuşmazlık, tünele değil muhasebeye baktığınız anlamına gelir.

Konteyner veya birkaç ad alanı çalıştıran bir ana bilgisayarda bir tanımlayıcı bir görünümde anlamlı olabilir, diğerinde bulunmayabilir. Bir süreci görememek de, hesabınız onu inceleyemiyorsa, yokluğunun kanıtı değildir. Sonuç çıkarmadan önce başlatıcının kullandığı bağlamdan denetleyin.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Başlatıcı dosyayla ne yapmayı vaat etmişti

PIDFile= hizmet yöneticisine ana sürecin tanımlayıcısının nereden okunacağını söyler. Yönetici o dosyayı yazmaz, ancak kapanmadan sonra kalanı kaldırır ve kesintiye uğramış bir çıkışın dosya bırakabilmesinin nedeni tam olarak budur.

Bu sorumluluk paylaşımı, insanların hata olarak bildirdiği iki belirtiyi açıklar. Hiç görünmeyen bir dosya, arka plan sürecinin ya da betiğinin onu yazamadığı anlamına gelir, denetimin yanlış yapılandırıldığı değil. Bir durdurmadan sonra kalan dosya, kapanma yolunun hiç tamamlanmadığı anlamına gelir.

Bu ayrıca, denetim ana süreci doğrudan izleyebildiğinde mevcut yönergelerin bu geleneği neden önermediğini açıklar. Bu yönergeler paketlenmiş bir birimin türünü değiştirme izni değildir, çünkü arka plan sürecinin ön planda, dallanmada veya bildirimde davranışı birimin bildirdiğiyle eşleşmelidir. Türü arka plan sürecini değiştirmeden değiştirin ve tünel çalışırken hata bildiren bir birim elde edersiniz ya da tam tersini. Çifti eşleştirin ya da ikisini de bırakın. systemd hizmet başvurusu bu sahiplik paylaşımını açıklar.

Temiz kapanma ile kesintiye uğramış çıkış

Temiz bir durdurma arka plan sürecinden çıkmasını ister, onu bekler ve yöneticinin kendi muhasebesini düzenlemesine izin verir. Kesintiye uğramış bir çıkış, öldürülmüş bir süreç veya kapanmanın ortasında bir yeniden başlatma bu dizinin parçalarını atlar ve geriye kalan dosyadır. Bir çökmeden sonra bir tane bulmak, kapanmanın tamamlanmadığını söyler, bir şeyin dinlediğini değil.

Dosyanın zaman damgasını son önyükleme ve birimin son durdurulmasıyla karşılaştırın.

Sonra canlı kanıtları doğrudan denetleyin. VPN bağlantı noktasına bağlı bir soket ve adresi olan bir tünel arayüzü, bir şeyin çalıştığının kanıtıdır; çalışma zamanı dizinindeki bir metin dosyasının asla olamayacağı biçimde. İkisi de yoksa, dosya ne iddia ederse etsin hiçbir şey çalışmıyor.

Dosyayı alışkanlık olarak silmeyi bırakın

Hiçbir örneğin ona sahip olmadığını ve başlatıcının bu davranışı belgelediğini saptadıktan sonra silmek meşru bir kurtarma adımıdır.

Başlamadan önceki kalıcı bir alışkanlık olarak, atlatmaya çalıştığınız denetimi etkisiz kılar. Her temiz durdurmadan sonra eski dosyalar geri geliyorsa, yazan ile kapanma yaşam döngüsü yolun kime ait olduğu konusunda anlaşamıyor demektir ve bu anlaşmazlık düzeltilmeye değer hatadır.

Ana bilgisayara bağımsız bir giriş yolu tutun, normal yöneticisi üzerinden bir örnek başlatın ve ilk sonucu okuyun. Sıradaki kişi ya çalışan ya da kendini açıklayan bir birim alır.