Zadanie w tle (tj. Rozpoczęte za pomocą &) wciąż ma swoje stdin, stdout i stderr podłączone do terminala, w którym zostało uruchomione. Może nagle zapisać (np. Komunikaty o błędach) do terminala („zakłócając” zadanie w pierwszy plan) lub wstrzymaj oczekiwanie na dane wejściowe z klawiatury (musisz najpierw umieścić je na pierwszym planie). Możesz oczywiście przekierować stdout i stderr do pliku lub do / dev / null, aby zapobiec zapisaniu zadania w tle do terminala.
Zadanie w tle można również umieścić na pierwszym planie - np. bieżące zadanie pierwszoplanowe zostaje zatrzymane, a polecenie fg(pierwszy plan) służy do umieszczenia zadania pierwszoplanowego na pierwszym planie. Do zadania w tle można także dotrzeć za pomocą sygnałów z terminala - np. SIGHUP po zamknięciu terminala, które zwykle kończą (większość) programów uruchomionych w terminalu.
Demon - podobnie jak te uruchamiane automatycznie przez init.d, ale który można również uruchomić ręcznie z terminala - z drugiej strony działa odłączony od jakichkolwiek terminali. Nawet jeśli uruchomiono go ręcznie z terminala, demon zostanie odłączony od terminala, więc nie będzie mógł ani pisać (stdout, stderr), ani czytać (stdin). Jest również „odporny” na sygnały wysyłane „automatycznie” przez terminal. (chociaż możesz wysyłać do niego sygnały za pomocą kill -signal pid).
„Tło” i „pierwszy plan” odnoszą się do statusu procesu do jakiegoś terminala - czy to proces aktualnie kontroluje terminal, czy nie. Ponieważ demony nie są podłączone do terminala (ale zostały matematycznie odłączone od niego pod każdym względem), nie można powiedzieć, że działa w tle. Demony są po prostu uruchomione bez skojarzenia z terminalem - ani na pierwszym planie, ani w tle.
Jeśli użyjesz psopcji pokazujących, z którego terminala korzysta proces, zobaczysz, że zarówno zadania przed jak i w tle są powiązane z terminalem (np. Tty2). Z drugiej strony demony mają znak „?” w tej dziedzinie.
Demony zwykle zachowują się jako takie, nawet jeśli są uruchamiane ręcznie. Stworzenie własnego demona jest dość pracochłonne - istnieją pewne sztuczki, aby całkowicie odłączyć go od terminala. Powinieneś utworzyć własnego użytkownika / grupę, aby działała jako. Zazwyczaj musisz użyć / tmp, / var / tmp lub / var / run, jeśli chcesz tworzyć pliki - zwykle nie powinien mieć żadnych praw w żadnym innym miejscu. Ponieważ nie może zgłaszać błędów do terminala, powinieneś go zapisać w pliku dziennika (np. Jego własny plik dziennika w / var / log). Demony powinny wprowadzić wpis w / var / run z bieżącym PID i sprawdzić, czy inna instancja już działa. Powinien respektować blokady (/ var / lock) dla plików lub urządzeń, w stosownych przypadkach. Powinien odpowiedzieć na SIGHUP, ponownie ładując swoje pliki konfiguracyjne i używając zaktualizowanych konfiguracji.
Kolejną kwestią jest to, jak działa większość demonów. Demon jest zwykle pojedynczym plikiem wykonywalnym, który może działać w jednym z dwóch różnych trybów; w zależności od tego, czy jest to oryginalny demon - rodzic - uruchamiany przy starcie, czy ręcznie ... lub dziecko odradzane przez tego rodzica. Proces nadrzędny zwykle po prostu siedzi i czeka na jakieś zdarzenie - określony czas, upływ czasu, próbę połączenia z określonym portem sieciowym lub cokolwiek innego. Kiedy tak się dzieje, rodzic tworzy proces potomny identyczny z samym sobą (za pomocą wywołania systemowego fork ()) - i natychmiast wraca do oczekiwania na kolejne zdarzenie (i może spawnuje więcej dzieci). Jest to proces potomny, który faktycznie wykona pracę - np. Zsynchronizowanie dysku, uruchomienie polecenia (np. cron) Lub nawiązanie połączenia sieciowego (np. sshdLubftpd). Jedyną różnicą między rodzicem a dzieckiem jest to, że mają różne PID, a PPID (Parent-PID) dziecka jest PID procesu nadrzędnego - można to wykorzystać do ustalenia, czy proces jest rodzicem, czy dzieckiem. Tak więc ten sam proces musi być w stanie działać w dwóch trybach - jako oczekujący (i spawnujący) rodzic lub jako pracujące dziecko.
Chociaż napisanie demona nie jest trudne, nie jest też trywialne - ponieważ widzisz, że jest kilka „sztuczek”, o których musisz najpierw wiedzieć. Ogólnie rzecz biorąc, pomyślałem, że napisanie demona wymagałoby dużo wysiłku przy bardzo niewielkim zysku w porównaniu z innymi alternatywami:
Użycie nohuplub disownw tle jest zazwyczaj wystarczającą alternatywą, ponieważ utrzymuje proces przy życiu, nawet jeśli terminal zostanie zamknięty. Często dobrym pomysłem jest przekierowanie stdout i stderr do pliku lub do / dev / null. W przypadku bardziej interaktywnych programów screenjest to dobry sposób, aby odłożyć coś „na bok”, dopóki go nie potrzebujesz. at, batchA crontabtakże warto concider.