2014-09-25 11 views
7

Pracuję nad aplikacją ze składnicą danych REDIS. Aby zachować integralność danych, chciałbym wyczyścić sklep podczas zamykania procesu.Kiedy proces Node.js może wyjść() bezpośrednio, bez uruchamiania innych zdarzeń sygnału (uncaughtException, SIGINT, SIGTERM ...)

Utworzono funkcję obsługi i powiązałem ją (z process.on()), aby sygnalizować zdarzenia: uncaughtException, SIGINT, SIGTERM, SIGQUIT i działa dobrze (CTRL + C, procesowe zabijanie, wyjątek, ...).

Ale przeczytałem, że w pewnych warunkach proces może zakończyć się bezpośrednio bez wywoływania innych zdarzeń sygnału.

Problem w tym konkretnym przypadku polega na tym, że procedura process.on ('exit') może przetwarzać tylko zadania synchroniczne.

Zrobiłem inny test, aby spróbować zabić proces na różne sposoby. I (z wyjątkiem SIGTERM na Windows) nie udało mi się zidentyfikować przypadku, w którym process.on ("exit") jest uruchamiany bezpośrednio, bez włączania SIGINT, SIGTERM lub innego zdarzenia.

Moje pytanie brzmi (w systemie Linux), w jakich warunkach proces może zakończyć się bezpośrednio, bez wywoływania tego zdarzenia: http://nodejs.org/api/all.html#all_signal_events?

+0

Dobre pierwsze pytanie, witamy w SO:), także, gdzie przeczytałeś o innych warunkach? To może być dobry punkt wyjścia do badań. – DrakaSAN

+0

W sprawie tego komentarza przynajmniej autor mówi: https://github.com/Automattic/socket.io-redis/pull/15 _ "Nie udało mi się poprawnie wykonać czyszczenia wyjścia, ** więc po normalnym exit **, pokoje są nadal wypełnione tymi samymi (obecnie nieistniejącymi) identyfikatorami gniazd. Rezygnacja z Ctrl + C lub sygnał zabicia powinien działać zgodnie z oczekiwaniami. "_ Może więc mógłbym zapytać bezpośrednio, co to jest" normalne wyjście " znaczy. – damien

+0

To byłby dobry pomysł, nie widzę, jak może "wyjść normalnie" bez kodu przechodzącego w jedno zdarzenie procesu ... – DrakaSAN

Odpowiedz

7

Jak teraz, czytając documentation i robi jakieś research, wydaje się, że jest tylko cztery sposób, w jaki node.js aplikacja exit:

Zwykle zdarza się, że ktoś nie rozumie komunikatu o błędzie z powodu wyjątku UncaughtException i błędnie sądzi, że to "coś innego" zabiło node.js.

+1

To nie do końca poprawne. Kiedy proces jest faktycznie zakończony bezpośrednio przez sygnał (jak w przypadku SIGABRT, jako typowy przykład), nie ma możliwości obsłużenia sygnału.Program może obsłużyć sygnał, a następnie wyjść, ale z perspektywy systemu operacyjnego (jak podaje rodzina wait (2)), sygnał nie zakończył procesu - po prostu wyszedł normalnie. –

+0

@DavePacheco: Jednak zdarzenie 'process.on ('SIGABRT')' nadal będzie wykonywane, nawet jeśli system operacyjny uzna, że ​​program zakończył się normalnie. – DrakaSAN

0

Rzeczywiście. Chciałem tylko wskazać, że programy Node mogą wychodzić w wyniku sygnału bez wykonania procedury obsługi (jeśli żadna nie została zarejestrowana). Przeglądając Twój wpis, widzę, że może to być również to, o czym myślałeś.

Powiązane problemy