processo vs demone

[sopadj1]

mi sono documentato ma nn ancora riesco a capire quali sono realmente le differenze tra servizi e demoni....

chi mi illumina?

[Ikitt]

Originariamente inviato da sopadj1
mi sono documentato ma nn ancora riesco a capire quali sono realmente le differenze tra servizi e demoni....
chi mi illumina?

Piu` o meno:
un demone e` un processo (ovviamente ), ma ovviamente non tutti i processi sono demoni. Un demone deve eseguire alcune operazioni particolari per definirsi tale, del tipo staccarsi dal terminale (non basta un & in fondo, per intendersi), comunicando con l'esterno non appunto tramite esso ma tramite file/rete/pipe/syslog.

Un servizio (nel senso comunemente inteso del termine) non e` necessariamente un demone che viene lanciato, puo` essere anche un qualsiasi insieme di azioni che e` conveniente impostare (automaticamente) al boot, tipo ripulire /tmp, caricare le regole di iptables...

[UNIX-based]

è (sempre) possibile deamonizzare un processo?
e... com'è la storia di file/rete/pipe/syslog?

grazie

[Ikitt]

Originariamente inviato da UNIX-based
è (sempre) possibile deamonizzare un processo?
e... com'è la storia di file/rete/pipe/syslog?

Groan, ero rimasto generico proprio perche` non ho molta esperienza sull'argomento (di demoni ne ho usati tanti, sbuzzati un paio e scritto nessuno )

Vabbuo`, vediamo spremere lo spremibile

Dunque, per quel che ne so, un demone e` semplicemente un programma non-interattivo (nel senso 'classico del termine', ovvero che non si aspetta un utente sempre davanti a se per funzionare e per il controllo, ma ovviamente puo` interagire con gli utenti, vedasi postfix/apache/vsftpd...) che gira indefinitamente (salvo crash) e non si appoggia ad un terminale per l'I/O.

Vediamo di aumentare il rischio (per me) di figure meschine scendendo nel dettaglio

Il punto grosso e` "non si appoggia ad un terminale". Un daemon non si aspetta input da terminale, e non lo spara su terminale, perche` molto verosimilmente, nessuno sara` in grado di gestirlo. Molto spesso, tale terminale non esistera` neppure:

 PID  TTY TIME    CMD
  769 ?        00:00:00 udevd
 2981 ?        00:00:00 khubd
 3050 ?        00:00:00 ifplugd
 3472 ?        00:00:00 syslogd
 3485 ?        00:00:00 klogd
 3500 ?        00:00:00 xinetd
 3563 ?        00:00:00 acpid

(estratto da un mio ps -A)

Ora: basta lancirare un comune programma col ben noto & finale per renderlo un daemon?
No, perche`)
1) tutto questo avviene comunque a partire da un terminale, e il daemon non dovrebbe farvi affidamento (vabbeh, questa e` teorica come motivazione)
2) il processo, molto porbabilmente continuerebbe a fare I/O appoggiandosi al terminale questo e` semplicemenre sbagliato, per un daemon. Questo non si puo` correggere, salvo rari casi e vari contorsionismi; dev'essere il programma stesso a prevederlo esplicitamente, cosi` come una modalita` daemon
3) se chiudo/ammazzo il processo lanciante (shell) mi muore anche il wannabe-daemon, anche qui salvo rari casi e contorsionismi vari (nohup). In generale, ci sono altre problematiche connesse a questo problema.

Per risolvere il punto 2, come detto, il programma, qualora preveda una "daemon-izzazione" deve comportarsi di conseguenza, solitamente chiudendo stdin/stdout/stderr.
La maggior parte dei daemon che fanno qualcosa di utile ha bisogno di fare I/O col mondo esterno, e cosi` devono entrare in gioco altri meccanismi: socket, pipe, ma anche segnali (controllo) e syslog (messaggi di stato/errore).

Per il punto 3, ci sono varie syscall, tra cui setsid. Questo e` un punto dove sono particolarmente poco documentato, per cui rimando a testi tipo GAPiL che saranno sicuramente essere piu` precisi ed esaurienti.

HTH,

[Boromir]

http://www.linuxinside.it/articolo.p...dei%20processi