Avviare servizi tramite inittab

[miklos]

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

Codice: Seleziona tutto

bean:345:respawn:su nobody -c 'exec /usr/bin/beanstalkd'

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?!?!?!

[masalapianta]

è 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.

[miklos]

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à.

ciau e grazie

[notsafe]

per me è stato come un fulmine a ciel sereno in quanto non ho mai visto fare una cosa del genere

allora non hai mai avuto a che fare con sistemi crackati

[masalapianta]

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

un esempio di cosa?

[masalapianta]

per me è stato come un fulmine a ciel sereno in quanto non ho mai visto fare una cosa del genere

allora non hai mai avuto a che fare con sistemi crackati

o con qmail :P