Riferimento per la corretta gestione del file PID su Unix

Dove posso trovare un riferimento ben rispettato che dettagli la corretta gestione dei file PID su Unix?

Sui sistemi operativi Unix, è pratica comune “bloccare” un programma (spesso un demone) usando un file di blocco speciale: 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 PID esiste e, se il file esiste, uscire con un errore. Quindi è una sorta di meccanismo di blocco collaborativo e consultivo.

Il file contiene una singola riga di testo, essendo l’ID del processo numerico (da cui il nome “file PID”) del processo che attualmente detiene il blocco; questo consente 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 al comportamento previsto o “best practice” per la gestione dei file PID. Ci sono varie sfumature: come bloccare effettivamente il file (non preoccuparti? Usare il kernel? Per quanto riguarda le incompatibilità della piattaforma?), Gestire i blocchi stantii (cancellarli silenziosamente? Quando controllare?), Quando esattamente acquisire e rilasciare il blocco , e così via.

Dove posso trovare un riferimento rispettato e autorevole (idealmente a livello di W. Richard Stevens) per questo piccolo argomento?

Per quanto ne so, i file PID sono una convenzione piuttosto che qualcosa per cui è ansible trovare una fonte autorevole e autorevole. Il più vicino che ho trovato è questa sezione del Filesystem Hierarchy Standard.

Questa libreria Perl potrebbe essere utile, dal momento che sembra che l’autore abbia almeno riflettuto su alcuni problemi che possono sorgere.

Credo che i file in / var / run siano spesso gestiti dai manutentori della distro piuttosto che dagli autori dei daemon, dal momento che è responsabilità dei manutentori della distro assicurarsi che tutti gli script di init funzionino bene insieme. Ho controllato la documentazione degli sviluppatori di Debian e Fedora e non sono riuscito a trovare linee guida dettagliate, ma potresti essere in grado di ottenere maggiori informazioni sulle mailing list dei loro sviluppatori.

Prima di tutto, su tutti i moderni UNIX /var/run non persistono attraverso i riavvii.

Il metodo generale di gestione del file PID consiste nel crearlo durante l’inizializzazione e cancellarlo da qualsiasi uscita, normale o gestore di segnale.

Esistono due modi canonici per creare / verificare atomicamente il file. Il principale in questi giorni è aprirlo con il flag O_EXCL : se il file esiste già, la chiamata fallisce. La vecchia maniera (obbligatoria sui sistemi senza O_EXCL ) è di crearla con un nome casuale e collegarsi ad essa. Il collegamento fallirà se il bersaglio esiste.

Vedere Interfaccia di programmazione Linux di Kerrisk, sezione 55.6 “Esecuzione di una sola istanza di un programma” che si basa sull’implementazione di pidfile in Unix Network Programming di Stevens, v2.

Si noti inoltre che la posizione del file pid è solitamente gestita dalla distro (tramite uno script init), quindi un demone ben scritto prenderà un argomento della riga di comando per specificare il file pid e non permettere che questo venga sovrascritto accidentalmente da un file di configurazione. Dovrebbe anche gestire con grazia un file pid stantio da solo (O_EXCL non dovrebbe essere usato). Dovrebbe essere usato il blocco del file fcntl (), si può presumere che il file pid di un demone si trovi su un filesystem locale (non NFS).

A seconda della distribuzione, è in realtà lo script di init che gestisce il file pid. Controlla l’esistenza all’avvio, rimuove l’arresto, ecc. Non mi piace farlo in quel modo. Scrivo i miei script di init e in genere non utilizzo le funzioni di init di stanard.

Un programma ben scritto (demone) avrà un qualche tipo di file di configurazione che dice dove dovrebbe essere scritto questo file pid (se presente). Sarà inoltre necessario stabilire i gestori di segnale in modo che il file PID venga ripulito all’uscita normale o anormale, ogni volta che un segnale può essere gestito. Il file PID fornisce quindi allo script di init il PID corretto in modo che possa essere fermato.

Pertanto, se il file pid esiste già all’avvio, è un ottimo indicatore del programma che si è arrestato in precedenza e dovrebbe eseguire una sorta di sforzo di recupero (se applicabile). È una specie di ripresa di quella logica nel piede se si ha lo script di init stesso che controlla l’esistenza del PID o lo scollega.

Per quanto riguarda lo spazio dei nomi, dovrebbe seguire il nome del programma. Se stai iniziando con ‘foo-daemon’, sarebbe foo-daemon.pid

Dovresti anche esplorare / var / lock / subsys, tuttavia questo è usato principalmente sugli aromi di Red Hat.

Il pacchetto systemd su Red Hat 7 fornisce un daemon(7) pagine man daemon(7) con la riga di intestazione “Demoni di sistema di scrittura e packaging”.

Questa pagina man descrive la demonizzazione “vecchio stile” (SysV) e “nuovo stile” (systemd). In un nuovo stile, systemd stesso gestisce i file PID per te (se configurato in tal modo). Tuttavia, in vecchio stile, la pagina man ha questo da dire:

  1. Nel processo daemon, scrivi il daemon PID (come restituito da getpid ()) in un file PID, ad esempio /run/foobar.pid (per un demone ipotetico “foobar”) per assicurarti che il daemon non possa essere avviato più di una volta . Questo deve essere implementato in modo libero da gara in modo che il file PID venga aggiornato solo quando viene verificato allo stesso tempo in cui il PID precedentemente memorizzato nel file PID non esiste più o appartiene a un processo esterno.

Puoi anche leggere questa pagina man online .