# Passare una variabile allo script local.stop

## oleo

Ciao a tutti!

Nel local.stop ho scritto un piccolo script che effettua alcuni backup con rsync.

Queste operazioni sono molto lente, perciò vorrei poterle bypassare quando necessario (specialmente quando devo fare un reboot).

Avevo in mente una cosa simile a questa:

```
FAST_SHUTDOWN="yes" reboot
```

Il problema è che lo script local.stop non riesce a leggere le variabili.

C'è un modo per poter passare una variabile allo script local.stop?

Grazie dei suggerimenti,

Fabio.

PS: Volendo cercare nei forum la parola "local.stop" come devo fare? Me la sostituisce sempre con "stop"...   :Rolling Eyes: 

----------

## comio

 *oleo wrote:*   

> Ciao a tutti!
> 
> Nel local.stop ho scritto un piccolo script che effettua alcuni backup con rsync.
> 
> Queste operazioni sono molto lente, perciò vorrei poterle bypassare quando necessario (specialmente quando devo fare un reboot).
> ...

 

l'unica che vedo è scrivere su un file qualcosa e poi leggerlo da local.stop (che riscrive con un valore neutro).

ciao

----------

## oleo

Era il piano B...   :Smile:   ...fare uno script tipo 

```
fast_reboot.sh
```

 che setti un valore dentro un file... ma mi piaceva di più l'altra soluzione, se fosse stata realizzabile.

Facendo uno script, posso renderlo eseguibile da qualsiasi punto, come un normale comando?

----------

## comio

 *oleo wrote:*   

> Era il piano B...    ...fare uno script tipo 
> 
> ```
> fast_reboot.sh
> ```
> ...

 

in generale sì

non puoi fare il suid per motivi di sicurezza (solitamente).

ciao

----------

## djinnZ

 *oleo wrote:*   

> C'è un modo per poter passare una variabile allo script local.stop?

 

Di norma no non si può passare una variabile ambiente ad rc od esportarla da esso, l'ambiente dell'rc è a se stante (per molti motivi strorici e non che non sto ad elencare) e viene ricaricato, se anche funzionasse sarebbe un errore.

La soluzione più pulita è utilizzare un file come semaforo.

lanci un semplice 

```
touch /tmp/fastboot
```

 e 

```
[ -e /tmp/fastboot ] || { rm /tmp/fastboot ; rsync vattelappesca }
```

 in local.stop

In ogni caso penserei a spostare il backup automatico dallo shutdown al boot, sempre che non sia una tua esigenza specifica.

edit: dipende dallo script cosa deve fare. Se devi accedere a qualche funzione particolare ricorda che devi richiamere l'ambiente con un source /etc/profile od un . /etc/bashrc etc. e specificare #!/bin/bash nell'intestazione.

Non dimenticare che local.st* sono degli script richiamati con "." e non eseguiti direttamente.

Per fare meglio farei un rc script separato, in realtà local è definito per semplici operazioni quali attivare disattivare il suono e soprattutto valide per tutti i runlevel.

A questo punto potresti anche optare per un runlevel dedicato alla manutenzione.

----------

## oleo

 *djinnZ wrote:*   

> Di norma no non si può passare una variabile ambiente ad rc od esportarla da esso, l'ambiente dell'rc è a se stante (per molti motivi strorici e non che non sto ad elencare) e viene ricaricato, se anche funzionasse sarebbe un errore.

 

Grazie mille per la delucidazione.

 *djinnZ wrote:*   

> In ogni caso penserei a spostare il backup automatico dallo shutdown al boot, sempre che non sia una tua esigenza specifica.

 

Il PC in questione è un server che fa da router e da PDC... il boot deve essere quanto più rapido possibile mentre lo shutdown (effettuato di notte) può impiegare tutto il tempo che vuole... tranne quando io devo fare manutenzione.  :Smile: 

Ho appena finito di implementare la soluzione con un semaforo... domani guarderò come fare per rendere lo script avviabile da qualsiasi punto.

Grazie ragazzi,

Fabio.

----------

## djinnZ

 *oleo wrote:*   

> Il PC in questione è un server che fa da router e da PDC... il boot deve essere quanto più rapido possibile mentre lo shutdown (effettuato di notte) può impiegare tutto il tempo che vuole... 

 

per evitare problemi invece è lo shutdown che deve essere il più veloce possibile. E se manca la corrente?

La mia soluzione è: script separato per il backup eseguibile anche da shell normale, rc-script in avvio che verifica se il backup non è stato fatto altrimenti lo fa (o blocca tutto se non è stato messo su cd da più di una settimana), azione acpi di spegnimento invece del solito "shutdown -h now" "{ backup.sh ; shutdown -h now }".

@comio

su lo puoi invocare quando vuoi, sudo dovrebbe avere qualche problema di path però ma basta caricare l'ambiente completo.

----------

## Kernel78

 *djinnZ wrote:*   

> per evitare problemi invece è lo shutdown che deve essere il più veloce possibile. E se manca la corrente?

 

Se manca la corrente ci sono due possibilità:

- non ha un UPS ed è fregato in ogni caso

- ha un UPS e nut (o il sw che usa per monitorarlo) è configurato per lanciare lo shutdown nella modalità "veloce"

----------

## oleo

 *djinnZ wrote:*   

> La mia soluzione è: script separato per il backup eseguibile anche da shell normale, rc-script in avvio che verifica se il backup non è stato fatto altrimenti lo fa (o blocca tutto se non è stato messo su cd da più di una settimana), azione acpi di spegnimento invece del solito "shutdown -h now" "{ backup.sh ; shutdown -h now }".
> 
> 

 

Non ho capito una cosa: a lato pratico che differenza c'è ad eseguire il backup prima di invocare lo shutdown e ad eseguirlo nel local.stop? E, cosa intendi con "blocca tutto" se non è stato...?

Poi: non c'è modo di lanciare comandi al boot senza però bloccare tutto? Una specie di "background" di un rc-script al boot... lo script viene lanciato, va in background e la procedura di boot continua. 

 *Kernel78 wrote:*   

> Se manca la corrente ci sono due possibilità:
> 
> - non ha un UPS ed è fregato in ogni caso

 

Non ho l'UPS quindi se manca la corrente sono fregato... però mi piace la tua idea visto che l'UPS sarà uno dei prossimi acquisti.

----------

## Kernel78

 *oleo wrote:*   

> Poi: non c'è modo di lanciare comandi al boot senza però bloccare tutto? Una specie di "background" di un rc-script al boot... lo script viene lanciato, va in background e la procedura di boot continua.

 

Certo basta mettere una & in fondo alla riga con cui si invoca il backup e questo viene messo in background.

----------

## djinnZ

 *oleo wrote:*   

> Non ho capito una cosa: a lato pratico che differenza c'è ad eseguire il backup prima di invocare lo shutdown e ad eseguirlo nel local.stop?

 

le operazioni in rc sono solo funzionali al sistema e si cerca di evitare operazioni lunghe e critiche. In più se il senso è avere la sicurezza che il giorno dopo non si lavori senza un backup non ne hai comunque la certezza.

 *oleo wrote:*   

> E, cosa intendi con "blocca tutto" se non è stato...?

 

Esempio: la contabilità ha backup giornaliero su disco apposito ed export su cd settimanale. Ogni volta che il sistema viene avviato controlla che ci sia un backup da meno di un giorno altrimenti lo fa a forza, poi controlla che l'export su cd sia stato fatto da meno di una settimana, in caso contrario chiede il cd ed effettua la copia. Se non gli dai il cd in pasto ti risponde con bel "idiota, se non fai i backup non puoi lavorare" (prima era "pezzodimm***** se non fai stò..." ma il capo me lo ha fatto cambiare a forza, adoro festival  :Twisted Evil: ) e si spegne.

Prima lo avevo messo alla fine ma mi è capitato che un individuo di incerta paternità che bazzicava per lo studio avesse l'abitudine di levare la spina e no  fare le copie, quando il disco, sollecitato anche da questa violenza, ha deciso di andarsene in gloria l'ultima copia risaliva a due mesi prima.

Mettendolo in avvio sei certo che non si possa iniziare a lavorare senza una copia fatta.

Se però non devi fare un backup ma pubblicare qualcosa è più logico ragionare al contrario e metterlo alla chiusura. Se devi fare il commit di un cvs su cui lavorano più persone lo metti sia alla chiusura che all'avvio, ovviamente.

In ogni caso eviterei local.stop ed adotterei uno script rc dedicato, di modo da poter sempre avere un runlevel per manutenzione senza backup (se sei a disco pieno o sei in ro come usi il semaforo? Per divina provvidenza?!).

Di modo che se vuoi lanci /etc/init.d/backup stop e ti esegue rsync etc o se te ne scordi sarà fatto allo shutdown. Indipendentemente dalla scelta di obbligarlo al boot od allo shutdown.

 *oleo wrote:*   

> Poi: non c'è modo di lanciare comandi al boot senza però bloccare tutto? Una specie di "background" di un rc-script al boot... lo script viene lanciato, va in background e la procedura di boot continua.

 

Assolutamente no. Non è corretto quel che hai in mente. (poi per il resto sei su un sistema unix like, quindi puoi sempre fare quel che ti pare, basta un &, ma non è una buona cosa)

----------

## oleo

Ottimo! Grazie mille per le dritte e le spiegazioni! Ci studierò un po' sopra...  :Smile: 

Fabio.

PS: Festival è davvero spettacoloso!   :Laughing:   ...lo usavo su di un robottino all'università con su EPIA e Gentoo e gli facevo dire delle cose da chiodi, in giro per i corridoi!

----------

