Nie ma, czy jest polecenie nousr1?

Kilka moich regularnych programów ulega awarii (regularnie) z komunikatem „Sygnał 1 zdefiniowany przez użytkownika”. Wiem, że istnieje nohuppolecenie, ale czy istnieje nousr1polecenie? A może coś, co zrobi coś takiego, nohupale z USR1?

linux

— użytkownik2624632
źródło

Lepszym pytaniem może być, co w pierwszej kolejności wysyła sygnał usr1? Jeśli nic nie jest, komunikat wyjściowy może być po prostu mylący.

— Grant

Wygląda na to, że możesz mieć poważne problemy z „zwykłymi programami” ... po prostu wyłączenie sygnałów może nie skorygować lub umożliwić prawidłowe działanie podstawowych aplikacji. Zdecydowanie sugeruję, abyś dokładnie przeanalizował swoje środowisko przed wyłączeniem różnych rzeczy.

— mdpc,

@Grant: Zgadzam się. Czy istnieje narzędzie, które może mi powiedzieć, co wysyła te sygnały?

— user2624632,

Odpowiedzi:

Proste hacky rozwiązanie, które ma narzędzie analogiczne do nohup, ale dla SIGUSR1, byłoby pobrać kopię źródła coreutils , rozpakuj go, zrób

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

, opcjonalnie zmień także nazwę pliku wyjściowego

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

, skompiluj to źródło i zainstaluj nowo skompilowany nohupplik binarny do /usr/bin/nousr1:

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

Następnie, jak sprawdziłem, sleep 1000wychodzi USR1, a jednocześnie nousr1 sleep 1000jest odporny na ten sygnał.

— Ruslan
źródło

nohupNawiasem mówiąc, główną funkcją jest oddzielenie procesu od terminala, aby nie był wysyłany SIGHUP. To, że konfiguruje również procedurę obsługi sygnału, jest dodatkowym bonusem, ale powinno być niepotrzebne.

— Simon Richter,

@ SimonRichter Jeśli usuniesz signal(SIGHUP,SIG_IGN);połączenie nohup.c, proces odbierze SIGHUP. Co nohuprobi oprócz ignorując sygnał jest tylko ponowne otwarcie stdin, stdout, stderr jak deskryptory plików nieterminalnymi. Nie oddziela tak naprawdę procesu od terminala w żaden szczególny sposób. Tj. Proces zostanie wysłany, SIGHUPgdy terminal się rozłączy. Z drugiej strony jest bash, który robi podobne rzeczy z disownpoleceniem, ale nie jestem pewien, jak to jest zaimplementowane - może w sposób, w jaki masz na myśli.

— Ruslan

To wydaje się działać dobrze.

— user2624632,

A co z trapwbudowanym poleceniem powłoki ?

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

— Janne Pikkarainen
źródło

Dobry pomysł, ale to nie zadziałało. Proces zakończył się mimo to z „Zdefiniowanym przez użytkownika sygnałem 1”.

— user2624632,

Procedury obsługi sygnałów (inne niż SIG_IGN i SIG_DFL) nie są dziedziczone przez procesy potomne.

— aecolley

Musisz użyć formy trappolecenia z pustym argumentem. Spróbuj tego:

trap '' SIGUSR1; myprogram

To zignoruje sygnał SIGUSR1, który właśnie próbujesz zrobić. Chociaż zgadzam się z komentatorami, że prawdopodobnie dzieje się tutaj więcej niż na pierwszy rzut oka.

Niepoprawna forma:

trap 'echo ...' SIGUSR1; myprogram

nadal pozwoli myprogramna otrzymanie SIGUSR1, ale powłoka wykona następnie polecenie echoz trappolecenia.

— Adrian Pronk
źródło

To wydaje się działać dobrze.

— user2624632,

Ups, mówiłem za wcześnie. Biegałam trap '' SIGUSR1; gvimdiff file1 file2i Vim zmarł z „vim: Caught śmiertelnie sygnalizować USR1”.

— user2624632,

Hmmm, patrząc na kod źródłowy na code.google.com/p/vim/source/browse/src/os_unix.c wydaje się, że VIM ponownie włącza sygnał USR1 i traktuje go jako błąd krytyczny. Jedyną nadzieją wydaje się być to, że możesz sprawić, że system operacyjny odmówi dostarczenia sygnału USR1. Nie wiem, czy istnieje coś, co może zapewnić taką funkcjonalność.

— Adrian Pronk

Więcej informacji tutaj: stackoverflow.com/q/4515274/41861

— Adrian Pronk

Adrian Pronk: to nie tylko Vim; to także Firefox, Aqualung, Thunderbird i kilka innych. Ale nie inne aplikacje, takie jak Konsola, która działa wiecznie.

— user2624632,