Lavorare con una macchina basata su Debian senza ventola. Tutti i filesystem sono su una scheda SD.
Il /var partizione è una voce fs ext2 separata in /etc/fstab .
Il sistema non ha un interruttore "on/off", quindi le persone tendono a tirare la spina per spegnerla e riaccenderla. Questo porta alla corruzione su /var partizione.
Voglio forzare il sistema a eseguire e2fsck ad ogni avvio.
Cosa ho provato:
-
Non montare /var all'avvio. Aggiungi script in /etc/rc2.d per eseguire e2fsck e quindi montare l'unità.
Problema:questo mi dà un sistema che pensa di essere bloccato al runlevel 6. Vedi qui. -
Usa tune2fs per impostare il ciclo fsck su un mount.
Problema:il sistema spesso si blocca durante l'avvio notando che /var è già montato e passa alla shell di manutenzione. -
Imposta il 6° bit in /etc/fstab a 2. Esegui
touch /forcefsck.
Problema:nessuno dei due/entrambi ha alcun effetto evidente. Il disco non è selezionato. -
Aggiungi noauto su /etc/fstab (vedi n. 1 sopra).
Problema:il sistema continua a montare la partizione, quindi viene visualizzato ancora un messaggio di errore.
Suggerimenti su altre cose da provare?
MODIFICA:
Alcuni retroscena:
- Abbiamo oltre 150 di questi sistemi distribuiti in località remote
- I sistemi in questione non hanno interruttori di accensione/spegnimento
- I sistemi vengono spesso (erroneamente) collegati a fonti di alimentazione commutate (interruttori a parete o altro)
- La perdita di alimentazione nella posizione in questione non è rara
Risposta accettata:
Questa domanda ha già avuto risposta:
Come forzare fsck ad ogni avvio - tutti i filesystem (rilevanti)?
Nessuno ha fatto notare che il vero problema sono le persone che tirano il cavo. Penso seriamente che l'attenzione su ENTRAMBE le domande sia sbagliata; Devi risolvere il problema dell'utente, non il problema del filesystem del server.
Onestamente, dato quanto sia cruciale questo filesystem per le funzionalità di base della macchina, la soluzione migliore è smettere di pensare a questo problema come un amministratore di sistema e iniziare a pensarci come un manager.
In altre parole:
- Insegna ai tuoi utenti come riavviare correttamente questo sistema per prevenire il problema di corruzione /var tanto per cominciare. La documentazione è tua amica, come si suol dire. Questa non è una soluzione ideale per molteplici ragioni, ma almeno impedisce loro di friggere i filesystem. Se non altro, non dovrebbero assolutamente toccare quella dannata cosa se il tuo lavoro è mantenerla in funzione.
- Chiudilo dove non possono accedervi. Seriamente, se si tratta di un server che memorizza dati importanti, perché non è già così? È un sistema di sviluppo e gli sviluppatori semplicemente non sanno cosa stanno facendo o quanto possa essere dannoso ?? Se è così, di nuovo, insegna loro. Non è compito tuo riparare gli stupidi, è tuo compito prevenire gli stupidi.
- Di' loro di lasciar perdere e di venire a parlare con te se ci sono problemi. 🙂
- Lo-tecnologico, ma forse utile (anche se un rischio di incendio di sicuro):nastro adesivo la merda da entrambe le estremità del cavo di alimentazione in modo che debbano passare 15 minuti cercando di stapparlo. Si spera che dopo cinque minuti e al livello 26 del nastro si sentano frustrati e facciano quello che dovrebbero fare:parla con te per risolvere il vero problema che li sta motivando a staccare la spina in primo luogo.
Che cos'è questa macchina che la rende così instabile che pensano sia necessario riavviarla ?? È un sistema Debian. Non hanno bisogno di "riavvii", quindi cos'altro c'è che non va ?? Sono preoccupati per il consumo di energia o ci sono servizi interrotti e instabili che solo un riavvio può risolvere? Se è quest'ultimo, la tua domanda è irrilevante e hai altro lavoro da fare, mi dispiace dirlo.
Se non altro, potresti avvicinarti al tuo suggerimento per essere bravo e non riavviare tirando il cavo come esercizio di risparmio energetico. Vuoi davvero alzarti dalla tua scrivania per tirare un cavo di alimentazione piuttosto che sederti lì, accedere e riavviarlo dalla riga di comando ?? Ci vogliono circa 2 secondi di lavoro per farlo in quel modo, invece di alzarsi, brontolare tutto il tempo fino al dispositivo, tirare il cavo, ricollegarlo, aspettare che torni su rotto, e poi devi attendi ancora di più per l'fsck di /var.
L'attesa del cavo per /var per risolverlo richiede molto più tempo, è molto più complesso da mantenere a lungo termine, causerà ogni tipo di dolore da parte tua, ti ha già motivato a porre le domande sbagliate e alla fine ti condurrà in cima a un campanile con un'arma d'amore e un desiderio di morte.
Risolvilo bene, riparando i tuoi utenti o mitigando il danno rendendo estremamente difficile per loro realizzare stupidaggini. Non posso essere più chiaro sull'importanza di questo.