Riferimento per la corretta gestione dei file di PID su Unix

Question

Dove posso trovare un di riferimento di tutto rispetto che descrive la corretta gestione dei file PID su Unix?

Nei sistemi operativi Unix, è pratica comune per “bloccare” un programma (spesso un demone) mediante l'uso di uno speciale file di blocco:. Il file PID

Questo è un file in una posizione prevedibile, spesso ‘/var/run/foo.pid’. Il programma dovrebbe controllare quando si avvia se il file esiste PID e, se il file esiste, uscita con un errore. Quindi è una sorta di consulenza, meccanismo di bloccaggio di collaborazione.

Il file contiene una singola riga di testo, essendo il processo ID numerico (da qui il nome “del file PID”) del processo che attualmente contiene il blocco; questo permette un modo semplice per automatizzare l'invio di un segnale al processo che detiene il blocco.

Quello che non riesco a trovare è un buon riferimento sul comportamento previsto o “best practice” per la gestione dei file PID. Ci sono varie sfumature: come bloccare effettivamente il file (non preoccupatevi utilizzare il kernel che dire di incompatibilità di piattaforma???), La manipolazione serrature stantii (silenziosamente cancellarli quando controllare??), Quando esattamente di acquisire e rilasciare il blocco , e così via.

Dove posso trovare un rispettata, riferimento più autorevole (idealmente a livello di W. Richard Stevens) per questo piccolo argomento?

Answer 1

Per quanto ne so, i file PID sono una convenzione piuttosto che qualcosa che si può trovare un rispettato, fonte autorevole per lo più. Il più vicino che ho trovato è questa sezione del Filesystem Hierarchy Standard.

Questa libreria Perl potrebbe essere utile, in quanto sembra che il autore ha almeno pensato a qualche problema che può sorgere.

Credo che i file in / var / run sono spesso gestite dai manutentori distro piuttosto che demoni autori, dal momento che è manutentori distro responsabilità di fare in modo che tutti gli script di init gioco piacevole insieme. Ho controllato documentazione per gli sviluppatori di Debian e Fedora di e non sono riuscito a trovare nessuna linee guida dettagliate, ma si potrebbe essere in grado di ottenere più informazioni sulle mailing list loro sviluppatori.

Answer 2

Prima di tutto, su tutti gli Unix moderni /var/run non persistono dopo il riavvio.

Il metodo generale di gestire il file PID è quello di creare durante l'inizializzazione e cancellarlo da ogni uscita, normale o segnale gestore.

Ci sono due modi canonici per creare atomicamente / verificare per il file. Il principale di questi giorni è quello di aprire con il flag O_EXCL: se il file esiste già, la chiamata non riesce. Il vecchio modo (obbligatorio sui sistemi senza O_EXCL) è quello di creare con un nome casuale e link ad esso. Il collegamento avrà esito negativo se esiste il bersaglio.

Answer 3

la programmazione Linux Interfaccia , sezione 55,6 " Running solo un esempio di un programma " che si basa sulla realizzazione pidfile a Stevens' di programmazione di rete Unix, v2.

Si noti inoltre che la posizione del pidfile è di solito qualcosa trattato dalla distribuzione (tramite uno script di init), in modo da un demone ben scritta avrà un argomento della riga di comando per specificare il pidfile e non permettere che questo essere accidentalmente sovrascritto da un file di configurazione. Si deve anche gestire con grazia un file pid stantio di per sé (O_EXCL non deve essere utilizzato). fcntl () il blocco dei file deve essere utilizzato -. si può supporre che pidfile di un demone è situato su un file system locale (non NFS)

Answer 4

A seconda della distribuzione, la sua realtà lo script di init che gestisce il pidfile. Controlla per essere alla partenza, rimuove quando si arresta, ecc non mi piace farlo in questo modo. Scrivo i miei script di init e in genere non utilizzare le funzioni stanard init.

Un programma ben scritto (demone) avrà un qualche tipo di file di configurazione dire dove deve essere scritto questo pidfile (se presente). Sarà anche fare attenzione a stabilire gestori di segnale in modo che il file PID viene ripulito il normale o anormale uscita, ogni volta che un segnale può essere gestito. Il file PID dà poi lo script di init il corretto PID in modo che possa essere fermato.

Pertanto, se il pidfile esiste già all'avvio, è un ottimo indicatore per il programma che in precedenza si è schiantato e dovrebbe fare una sorta di sforzo di recupero (se applicabile). Si tipo di riprese che la logica nel piede se avete la script di init per sé il controllo per l'esistenza del PID, o lo scollegamento di esso.

Per quanto riguarda lo spazio dei nomi, si deve seguire il nome del programma. Se si avvia 'foo-daemon', sarebbe foo-daemon.pid

Si dovrebbe anche esplorare / var / lock / subsys, tuttavia, che viene utilizzato per lo più su sapori Red Hat.

Answer 5

Il pacchetto systemd su Red Hat 7 fornisce una pagina man daemon(7) con la riga di intestazione "Scrittura e del sistema di confezionamento demoni".

Questa pagina di manuale descrive sia "vecchio stile" (SysV) e "nuovo stile" (systemd) daemonization. Nel nuovo stile, systemd stessa gestisce i file PID per voi (se così configurato per farlo). Tuttavia, in stile antico, la pagina man ha questo da dire:

  

  
12. Nel processo demone, scrivere il demone PID (come restituito da getpid ())          in un file PID, ad esempio /run/foobar.pid (per un ipotetico daemon          "Foobar") per garantire che il demone non può essere avviato più di una volta.          Questo deve essere implementato in modo libero-gara in modo che il file PID è          aggiornato solo quando si è verificata allo stesso tempo che il PID          precedentemente memorizzato nel file PID non esiste più o appartiene ad una          processo di stranieri.
  

Si può anche leggere questa pagina linea .