Po dwukrotnym wysłaniu sygnału TERM do pracownika Seler (zatrzymanie na ciepło i zimne wyłączenie) za pomocą przerwań klawiatury Ctlr-C, pracownik Seler jest po prostu zawieszony. Nie pochłania wiadomości ani nie wykonuje zadań (zgodnie z oczekiwaniami), ale też nie wyłącza się.Dlaczego Celery nie wyłącza się w sposób czysty?
Przeprowadziłem strace
w procesach selera, aby zobaczyć, co dzieje się za sceną. Oto wynik strace
na PID procesu głównego Seler
strace -p 27867
Process 27867 attached - interrupt to quit
futex(0xb966a78, FUTEX_WAIT, 0, NULL
i oto co znalazłem robi strace
na procesy dziecko:
strace -p 27874
Process 27874 attached - interrupt to quit
select(4, [3], NULL, NULL, {0, 562000}) = 0 (Timeout)
futex(0x871a808, FUTEX_WAKE, 1) = 0
select(4, [3], NULL, NULL, {1, 0}) = 0 (Timeout)
futex(0x871a808, FUTEX_WAKE, 1) = 0
......................................................
Wiem, że mógłbym wystawić sygnał KILL do procesów do pozbądź się ich. Ale ciekawi mnie, co tak naprawdę uniemożliwia zamknięcie tych procesów i czy można coś z tym zrobić.
Software stosu: Python 2.6.2, 2.4.6 selera, CentOS 5.0
UPDATE: Użycie procesora jest w dół do prawie 0%. Te zadania wymagają dość dużego obciążenia procesora, więc oznacza to, że żadne zadania nie są aktualnie aktywne.
Brak aktywnych zadań. Zadania, które zostały uruchomione w momencie wydawania sygnału stopu, zostały zakończone. Długość kolejki pozostaje taka sama. Nic nie jest wyprowadzane do dzienników. Ale procesy wciąż nie kończą się. Jak powiedziałem, mogę * wydać ZABIJ i pozbyć się ich. Ale to nie będzie skuteczne rozwiązanie. Aby niezawodnie używać tego oprogramowania, muszę być w stanie zatrzymać (i uruchomić) automatycznie z niewielką lub żadną ręczną interwencją. – rubayeet
Dobrym rozwiązaniem jest daemonizacja selera. Supervisord jest doskonałym kandydatem. – hymloth
Używam generycznych skryptów init do demonizowania pracowników: https://github.com/ask/celery/blob/master/contrib/generic-init.d/celeryd – rubayeet