Nohup var, nousr1 komutu var mı?

Düzenli programlardan birkaçı (düzenli olarak) "Kullanıcı tanımlı sinyal 1" mesajıyla kilitleniyor. Bir nohupkomut olduğunu biliyorum , ama bir nousr1komut var mı? Yoksa nohupUSR1 ile benzer bir şey yapacak mı?

linux

— user2624632
kaynak

Daha iyi soru, ilk etapta usr1 sinyalini gönderen şey olabilir mi? Hiçbir şey yoksa, çıkış mesajı yanıltıcı olabilir.

— Grant

"Normal programlarınızda" ciddi sorunlar yaşayabilirsiniz ... basitçe sinyalleri devre dışı bırakmak temel uygulamaların düzgün çalışmasını sağlamayabilir veya etkinleştirmeyebilir. Bir şeyleri devre dışı bırakmadan önce ortamınızı DİKKATLİ bir şekilde incelemenizi şiddetle tavsiye ederim.

— mdpc

@ Hibe: Katılıyorum. Bana bu sinyalleri ne gönderdiğini söyleyebilecek bir yardımcı program var mı?

— user2624632

Yanıtlar:

Yardımcı programa benzetmek için basit bir hacky çözümü nohup, ancak SIGUSR1, coreutils kaynağının bir kopyasını almak , paketten çıkarmak ,

sed -i 's/SIGHUP/SIGUSR1/' /path/to/coreutils/src/nohup.c

, isteğe bağlı olarak çıktı dosyasının adını da değiştirin

sed -i 's/nohup\.out/nousr1.out/g' /path/to/coreutils/src/nohup.c

, bu kaynağı derleyin ve yeni derlenen nohupikili dosyayı şu şekilde yükleyin /usr/bin/nousr1:

cp /path/to/coreutils/src/nohup /usr/bin/nousr1

Kontrol ettim bu sonra, sleep 1000ilgili çıkışları USR1iken nousr1 sleep 1000bu sinyale karşı bağışık değildir.

— Ruslan
kaynak

Bu nohuparada, ana işlevi , işlemi terminalden ayırmaktır, böylece SIGHUPilk etapta gönderilmez . Ayrıca bir sinyal işleyici kurması ek bir avantajdır, ancak gereksiz olmalıdır.

— Simon Richter

@SimonRichter Gelen signal(SIGHUP,SIG_IGN);aramayı kaldırırsanız nohup.cişlem SIGHUP. Ne nohupsinyali görmezden gelen bir kenara tıpkı terminal dışı dosyalar olarak Stdin, stdout stderr tanımlayıcılar yeniden açıyor. Süreci terminalden gerçekten özel bir şekilde ayırmaz. Yani, SIGHUPterminal kapatıldığında işlem gönderilecektir . Diğer tarafta orada benzer şeyi yapar bash, var disownkomutu, ama emin nasıl değilim o uygulanmaktadır - belki Şunu bir şekilde.

— Ruslan

Bu iyi çalışıyor gibi görünüyor.

— user2624632

Kabuk trapyerleşik komutuna ne dersiniz ?

trap 'echo "Thou shalt not USR1 me"' USR1

— Janne Pikkarainen
kaynak

İyi fikir, ama işe yaramadı. İşlem yine de "Kullanıcı tanımlı sinyal 1" ile sonlandırıldı.

— user2624632

(SIG_IGN ve SIG_DFL hariç) Sinyal işleyicileri edilir değil alt süreçler miras.

— aecolley

trapKomutun formunu boş bir argümanla kullanmanız gerekir . Bunu dene:

trap '' SIGUSR1; myprogram

Bu, yapmaya çalıştığınız SIGUSR1 sinyalini yok sayar. Her ne kadar yorumcularla aynı fikirde olsam da, muhtemelen burada gözle görülenden daha fazlası oluyor.

Yanlış form:

trap 'echo ...' SIGUSR1; myprogram

Hala sağlayacak myprogramSIGUSR1 almak ama kabuk sonra çalıştırır echogelen trapkomuta.

— Adrian Pronk
kaynak

Bu iyi çalışıyor gibi görünüyor.

— user2624632

Hata! Çok erken konuştum. Koşuyordum trap '' SIGUSR1; gvimdiff file1 file2ve Vim birlikte öldü "Vim: USR1 sinyali ölümcül yakalandı".

— user2624632

Hmmm, code.google.com/p/vim/source/browse/src/os_unix.c adresindeki kaynak koduna bakıldığında, VIM'in USR1 sinyalini yeniden etkinleştirdiği ve ölümcül bir hata olarak gördüğü anlaşılıyor. Eğer işletim sistemi USR1 sinyalini vermeyi reddedebilirseniz, tek umudunuz görünecektir. Orada bu işlevselliği sağlayabilecek bir şey olup olmadığını bilmiyorum.

— Adrian Pronk

Daha fazla bilgi için: stackoverflow.com/q/4515274/41861

— Adrian Pronk

Adrian Pronk: Sadece Vim değil; Firefox, Aqualung, Thunderbird ve diğerleri. Ancak Konsole gibi sonsuza dek çalışan diğer uygulamalar değil.

— user2624632