Re: [riminilug-general] Tips: Eseguire il boot in ordine sequenziale

[Umberto Zappi <uzappi@xxxxxxxxxxxx>]

Il 17 aprile 2014 02:04, Ivan Tarozzi <itarozzi@xxxxxxxxx> ha scritto:
>
> Il 16/04/2014 18:16, Umberto Zappi ha scritto:
>> Ciao a tutti,
>> qualche giorno fa ho avuto un problema di stampa tramite Cups da un
>> client verso un server avente la stampante condivisa.
>> In pratica il problema consisteva che il client non riusciva a trovare
>> in rete nessun servizio di stampa offerto da un server CUPS.
>>
>> Dopo un po' di tempo ho individuato che il problema consisteva
>> nell'errata sequenza dei servizi attivati sul server: avahi partiva
>> dopo di cups.
>>
>> Il server monta una distro Debian Jessie.
>>
>> Controllando con runlevel il runlevel corrente (= 2) e verificando in
>> /etc/rc2.d tutto sembrava corretto: il servizio Avahi doveva partire
>> prima di Cups, ma cio' non accadeva.
>>
>> Il problema è dovuto all'avvio in concorrenza dei servizi, quindi in
>> fase di boot non è detto che i servizi rispettino l'ordine impostato
>> linkando gli script di boot con i nomi del tipo Snn'script'
>>
>> Ormai avevo "gettato la spugna", ma prima ho voluto guardare
>> all'interno dello script /etc/init.d/rc e mi sono accorto che se
>> esiste il file nascosto /etc/init.d/.legacy-bootordering viene
>> impostata la variabile CONCURRENCY a "none" e l'avvio viene eseguito
>> in maniera tradizionale (tipo Unix System V).
>>
>> Ho fatto un bel touch /etc/init.d/.legacy-bootordering e ho risolto il
>> problema.
>>
>> Un saluto a tutti quanti.
>> UmbertoZ
>
> Grazie Umberto per la condivisione di questa tua esperienza! Ottimo
> esercizio e dimostrazione di come, avendo la possibilita' di guardare
> sotto al cofano (e le capacita' per farlo), spesso si trova una soluzione.
>
> Quindi, se ho capito bene, cosi' facendo hai disabilitato l'avvio
> concorrente dei servizi. Una curiosita': dopo aver fatto questa modifica
> hai rilevato dei sostanziali aumenti nel tempo di boot ?
>
> Ho letto che si sta valutando se passare da sysvinit a systemd (o
> upstart) ma credo che ancora non sia stata presa alcuna decisione.
>
> Ciao!
> Ivan
>

Ciao Ivan,
ho disabilitato l'avvio concorrente dei servizi.
In effetti cosi' facendo, c'e' un leggero aumento dei tempi in fase di
avvio, ma per fortuna rimane accettabile: una manciata di secondi.
Non e' nulla rispetto al tempo che ho impiegato (perso) per far
funzionare le cose.

L'aumento del tempo di avvio e' causato per lo piu' da quegli script
che impiegano un certo tempo per la loro esecuzione, magari senza
impegnare troppo la CPU.
Nella modalita' di concorrenza, il tempo di CPU inutilizzato durante
uno script, può venire utilizzato da un altro script.
Nella modalità sequenziale, lo script successivo verra' eseguito solo
quando lo script in esecuzione avra' terminato, lasciando inutilizzato
il tempo di CPU eccedente a quello necessario per l'esecuzione dello
script.

Provo a spiegarmi con un esempio (anche se e' un po' particolare),
giusto per farmi capire da tutti quanti.
Supponiamo che all'interno di uno script due comandi debbano essere
intervallati da un certo tempo, diciamo per fissare le idee 10
secondi.
Tra i 2 comandi ci potrebbe essere un altro comando del tipo sleep 10
che ritarda appunto di 10 secondi l'esecuzione tra un comando e
l'altro. In questo periodo di tempo la CPU rimane scarica e non fa
nulla (tra umani diremo che "si gira i pollici").
Nel caso di avvio sequenziale, venendo eseguito uno script alla volta,
questo tempo viene veramente perso.
Nel caso di avvio concorrente, se ci sono altri script da eseguire,
questi vengono portati avanti in parallelo durante i 10 secondi di
attesa dello script che ha chiesto la pausa.

Un altro esempio di attesa, potrebbe essere rappresentato (anziche' da
sleep) da un comando che attende un'operazione di I/O da un qualsiasi
device.

Ciao
UmbertoZ

---------------------------------------------------------------------
Per cancellarsi, scrivi a: riminilug-general-unsubscribe@xxxxxxxxxxxx
Se vuoi conoscere altri comandi, scrivi a: riminilug-general-help@xxxxxxxxxxxx