È arrivata una domanda su StackOverflow che chiedeva di scrivere init.dscript in Python. Un commento indicava che questi script dovevano essere programmati nella shell, non in Python. Scrive init.dscript in Python:
Sarebbe bello conoscere eventuali scenari da incubo, o se questa regola è scritta nel sangue di qualche amministratore di sistema.
Risposte:
Direi # 2, ma molto vicino al # 1 - "Cattivo. Cattivo. Cattivo. Non farlo mai." Lo standard, così com'è, per gli script di init Linux è nell'LSB , e mentre non esce mai e dice "questi sono script di shell bourne", vengono fatte diverse ipotesi. Uno, che le righe che iniziano con # sono commenti, sembra funzionare bene. Più problematico è il requisito che lo script init esegua i comandi da /lib/lsb/init-functions"nell'ambiente corrente (vedere il punto di comando integrato speciale della shell)".
Ma soprattutto, se stai facendo qualcosa di veramente complicato qui, lo stai facendo male. Gli script di init dovrebbero essere molto semplici e utilitari. Dovrebbero essere script nel senso classico, non programmi. È meglio succhiarlo e creare un semplice script di shell che qualsiasi amministratore di sistema può facilmente guardare in un sol colpo piuttosto che creare qualcosa di bello e progettato in Python.
Un'altra considerazione da tenere a mente è systemd che potrebbe essere o meno il futuro dell'inizializzazione di tutti i sistemi su Linux. Sotto systemd, l'inizializzazione viene eseguita da semplici file di configurazione anziché da script, con l'idea che tutto l'avvio si adatta a diversi modelli di progettazione standard e in realtà dovresti semplicemente sceglierne uno. Se il programma utilizza qualcosa di complicato per l'inizializzazione, questo dovrebbe andare al di fuori dello script init stesso.
Non vedo alcun problema, se si sa con certezza che l'interprete Python sarà disponibile quando viene eseguito lo script init.d. Questo, per me, indica che stai guardando qualcosa che viene fatto relativamente tardi in un livello di esecuzione multiutente (o "console grafica").
Tuttavia ... Ciò significa che una versione specifica dell'interprete Python PUO 'essere di vitale importanza per la sequenza di avvio e questa è un'altra cosa che devi verificare agli aggiornamenti.
Immagino che questo significhi che sto dicendo "3. OK, con avvertimenti".
Sono d'accordo con "3. OK, con avvertimenti", ma per motivi diversi. La mia esperienza su Solaris fu che avevano una copia del sistema operativo di Perl per alcuni dei loro programmi interni. Lo script della shell non era altro che la shell per far decollare il Perl. Lo script di avvio doveva essere scritto in sh? No, ma ha migliorato la manutenibilità per l'amministratore. E lo script di init non ha fatto nulla di più complicato di cose come daemon --starto daemon --stop. Se lo hai fatto, gli utenti regolari potrebbero avviare il tuo strumento in modalità senza privilegi, se ciò ha senso nel contesto del tuo programma. E non avrebbero bisogno di avere tutti i tipi di impostazioni complicate per la finezza.
Le moderne distribuzioni Linux, anche quelle ancora in uso init.d, hanno una vasta collezione di funzioni predefinite pensate per rendere semplice la gestione dei demoni. I processi di avvio grafici sfruttano sistematicamente quelle funzioni per mantenere il logo carino a meno che uno degli script di avvio non inizi a vomitare errori. Il tuo codice Python (o qualsiasi altra lingua) potrebbe non funzionare bene con questi schemi.
Se non ti interessa l'estetica o la manutenibilità, il tuo script init può essere scritto come vuoi. Ho visto molti amministratori, che non riescono nemmeno a tagliare e incollare correttamente, ignorano completamente gli argomenti della riga di comando e avviano semplicemente il demone. Nessun arresto, stato o riavvio. Era immaturo, ma il loro codice era ancora in esecuzione.
Dico tra # 1-2. L'LSB ti dirige in questo modo ... e da un amministratore di sistema (ruolo non dev) il lavoro richiede la conoscenza sh / bash, NON il livello dev (o anche la comprensione leggera) di python, PHP o perl. Questo è per lo stack LAMP, non per gli script di inizializzazione del sistema.