Demone <||> Differenze di controllo del processo

Rispetto a questo eccellente post:

https://stackoverflow.com/questions/958249/whats-the-difference-between-nohup-and-a-daemon

Vorrei chiedere quanto segue:

Dopo aver avviato un'applicazione dal mio terminale, l'applicazione continua a essere eseguita in background o in primo piano e l'unica cosa che posso fare per interagire con essa è l'invio di segnali dal mio terminale (dato che lo stdin è ancora in atto).

Tuttavia, dopo l'avvio di un processo daemon, mi sono reso conto che può essere controllato con mezzi extra (oltre ai segnali) come interrogarlo con flag come sotto (arch-way):

# /etc/rc.d/daemon-name {start|stop|restart|status|...}

Qualcuno potrebbe spiegarmi se tale funzione è integrata nel "daemon framework" generale e si applica a ogni processo daemon come funzionalità speciale o è solo una disposizione che i processi progettati per essere eseguiti come daemon devono gestire internamente?

E per aggiungere altro alla questione, come mai siamo in grado di "controllare" i demoni dal terminale usando il loro nome (cioè Sambad Stop) mentre le applicazioni devono sempre essere riferite usando il loro nome (cioè uccidere -9 12345)?

Grazie in anticipo!

— kstratis
fonte

Se capisco correttamente la domanda, quando si utilizza sambad stop, viene indicato anche dal numero PID, che è memorizzato nella directory / var / run / (o altro a seconda del sistema). Il file viene creato quando lo fai start.

Questa funzione non è integrata in quel deamon. Se modifichi /etc/rc.d/daemon-name, potresti vedere che è un semplice script bash, che esegue il processo con parametri specifici (gli argomenti possono essere definiti in quello script su Linux o in /etc/rc.conf su Unix). È possibile scrivere il proprio script di avvio e arresto con nome daemon.

Fondamentalmente:

start esegue il processo dal terminale (il processo sa automaticamente che dovrebbe essere eseguito in background, a volte c'è un argomento speciale come -d),
smetti di farlo ,kill -9 cat /var/run/daemon.pid
riavvia che sta facendo ,kill -HUP cat /var/run/daemon.pid
Stato che sta facendo qualcosa di simile a: .ps cat /var/run/daemon.pid

Inoltre, esistono diversi metodi di comunicazione rispetto all'invio dei segnali tramite socket unix. Ad esempio, è possibile controllare i processi inviando dbusmessaggi. Vedere:man dbus-send

Il seguente comando elencherà tutti i socket unix:

netstat -lp --unix

Puoi filtrarlo per dbus per:

netstat -lp --unix | grep -w dbus

Eseguendo dbus-monitorpuoi vedere come diversi processi possono comunicare tra loro.

Ecco qualche esempio di invio del messaggio all'altro servizio:

dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Leggi alcuni articoli utili:

— kenorb
fonte

Grazie. Questo è esattamente ciò di cui ero confuso. Ora, poiché i demoni sono praticamente semplici processi controllati da uno script (con alcune proprietà extra), potresti specificare se la funzionalità di un demone (o processo) in generale può essere modificata durante il runtime convocando il suo pid con un flag appropriato? (da non confondere con i demoni del server che ascoltano porte specifiche) ...

— kstratis,

Cosa intendi per alterarlo durante il runtime, puoi darmi qualche esempio? Esistono diversi segnali (vedi: man sigation) che è possibile inviare per modificare il processo. È possibile interrompere il processo tramite SIGSTOP o SIGCONT per riprenderlo, sulle macchine Unix è anche possibile ottenere alcune informazioni aggiuntive utilizzando il segnale SIGINFO.

— Kenorb,

Sì. Questo è esattamente il lavoro dei segnali. Il "problema" è che in teoria, dopo il lancio di un'applicazione / demone, non si ha alcun controllo su di esso - APART dall'invio del solito set di segnali -. Tuttavia, come esempio, di recente ho letto questo post su un nuovo editor di testo chiamato "Sublime Text" wesbos.com/sublime-text-2-tips che suggerisce che possiamo controllare l'editor con mezzi aggiuntivi usando il suo strumento cmd incluso che a sua volta ti permette di aggiungere file a un'istanza in esecuzione della finestra dell'editor principale ... Come è possibile dal momento che tutto ciò che possiamo fare su applicazioni già in esecuzione è segnalarli?

— kstratis,

Penso che dipenda dalle applicazioni, potrebbe creare alcuni socket unix locali (Vedi: netstat -na), socket TCP / IP standard o qualche tipo di semaforo (Vedi: ipcs –s), code di messaggi, ecc. Che vengono utilizzati per la comunicazione tra i processi. Esegui anche: lsof -p PID, per vedere tutti i gestori utilizzati dal processo.

— Kenorb,

Mi sono appena reso conto che la mia domanda si pone su se e come la comunicazione tra processi possa essere raggiunta ... e poiché mi mancava quel bit e sapevo solo di segnali unix semplici che non portano alcun tipo di informazione, alla fine mi sono confuso. Grazie a tutti per le risposte.

— kstratis,

La maggior parte delle funzionalità non è integrata nel demone, ma negli script init . Nel /etc/init.d/sambadci sarà il codice per tenere traccia del PID quando è iniziato e segnalarlo quando è necessario fermarsi. Gli script init sono in genere più specifici per la distribuzione che per il demone in questione poiché l'avvio del sistema e l'amministrazione del servizio sono una delle aree principali che le distribuzioni Linux usano per distinguersi.

La possibilità di ricaricare un file di configurazione senza uccidere e riavviare il demone è l'unica di queste azioni che richiede una quantità significativa di codice scritto all'interno del demone stesso.

— Alan Curry
fonte