Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Ciao a tutti, stavo preparando uno slackbuild per un servizio che utilizzo da poco e mentre stavo scrivendo lo script di avvio mi sono imbattuto in una discussione dove lo sviluppatore principale scrive
However, init.d scripts, especially when combined with processes that fork, are a terrible way to run services. I'm not going to encourage such an unreliable mechanism.
che invece consiglia, nella documentazione del progetto, di aggiungere una riga nell'inittab piu' o meno in questo modo
per me è stato come un fulmine a ciel sereno in quanto non ho mai visto fare una cosa del genere (o in tanti anni di slackware non me ne sono mai accorto ).
ad occhio mi vengono in mente stupidamente, due possibili vantaggi di questo approccio:
è possibile avviare separatamente diverse istanze dello stesso servizio con parametri diversi, cosa che con un singolo script di avvio viene piu' complicata
ad ogni crash del servizio si dovrebbe riavviare in autonomia
voi che ne pensate?!?!? è pura follia, oppure ha senso?!?!?!
è una cagata pazzesca (cit.), il respawn di init è pensato per servizi che debbono stare in piedi qualunque sia lo stato del sistema (come le getty), non per demoni che devono dipendere dal runlevel in cui ci si trova; se il signorino ha paura che un demone sfugga al controllo degli script di init con una doppia fork(), allora utilizzasse systemd (che usa i cgroups per tracciare i processi, anzichè i pid) invece di consigliare ste porcate.
masalapianta ha scritto:se il signorino ha paura che un demone sfugga al controllo degli script di init con una doppia fork()
che tra l'altro non è nemmeno questo caso visto che il servizio in questione non è demonizzabile nel senso che negli script che stavo preparando va lanciato in background.
pero' in ogni caso non riesco a capire questa 'problematica'. voglio dire se un demone sfugge al controllo con multipli fork il problema non sta nello script, ma nel demone.. giusto!??!?!
in caso contrario riesci, per favore, a farmi un esempio.. piu' che altro ora è diventata una mia curiosità.
miklos ha scritto:
pero' in ogni caso non riesco a capire questa 'problematica'. voglio dire se un demone sfugge al controllo con multipli fork il problema non sta nello script, ma nel demone.. giusto!??!?!
in generale, laddove è possibile, conviene avere meccanismi di controllo che gestiscano eventuali errori di programmazione (se così non fosse non avremmo cose come la modalità protetta ad esempio)
in caso contrario riesci, per favore, a farmi un esempio.. piu' che altro ora è diventata una mia curiosità.
ciau e grazie