Newsgroup: it.comp.os.linux.sys
Titolo: Spegimento senza shutdown

Salve, scusate se vi tedio, ma ho un problema singolare, vorrei un
parere e magari sapere se esiste una qualche soluzione tecnica.
La società in cui lavoro ha installato presso un cliente una 20ina di
macchine linux (Debian Woody) che acquisiscono dati da altrettanti PLC
(tramite socket TCP/IP), PLC che pilotano delle linee di montaggio.  Non
è la prima volta che usiamo linux in questo ambito, e non abbiamo mai
avuto problemi.
Precedentemente un'altra società aveva realizzato la stessa cosa basata
piattaforma Windows NT4.
Il problema è che le macchine che effettuano l'acquisizione dati vengono
sistematicamente spente dal personale operaio (che agisce su un
interruttore generale che disenergizza tutto il settore, quindi linea di
montaggio, PLC e PC) senza effettuare la procedura di shutdown, per cui
molto spesso all'avvio il sistema richiede la riparazione interattiva
del filesystem (con enorme disapprovazione del cliente, perchè i PC non
essendo presidiati rimangono fermi e non leggono più i dati dal campo).
Abbiamo raccomandato al cliente di effettuare sempre la procedura si
shutdown, ma la risposta è stata del tipo "non se ne parla nemmeno",
perchè, non possono gravare il personale operaio di compiti aggiuntivi
(la presenza dei PC deve essere assolutamente trasparente e non devono
richiedere alcun tipo di manutenzione). Inoltre non vogliono spendere
una lira per i gruppi di continuità (perchè secondo loro verrebbe a
cadere l'economicità della soluzione linux), e i settori non sono
raggiunti da punti rete. Sostengono inoltre che per anni hanno trattato
allo stesso modo le macchine con NT4 senza mai aver avuto problemi, e
*pretendono* che la nuova soluzione sia altrettanto insensibile agli
spegnimenti brutali (queste sono parole loro).
Per ovviare in parte, ho pensato di montare in "ro" tutti i filesystem e
mettere la /tmp in ramdisk, tenendo solo la /var in "rw" (la /var
contiene il db delle letture dai PLC ed è in PostgreSQL, precedentemente
su NT4 usavano MS Access!), ma il problema si ripresenta spesso (le
macchine vengono spente anche 3 volte in 24 ore). Ovviamente il
filesystem usato è lo ext3, e questo ha ridotto sensibilmente i casi di
richiesta di riparazione interattiva all'avvio rispetto all'ext2 usato
all'inizio, ma non li ha eliminati del tutto.
I pc _non_ sono i rete, per cui una soluzione di spooling su host remoto
non è adottabile (avrei così potuto montare localmente tutto in "ro").
Il cliente ha assunto una posizione rigida, dice che il problema è
nostro, che con NT4 funzionava tutto bene, e che loro non possono (e non
vogliono) cambiare operativa perchè l'esistenza di quei PC deve essere
trasparente. Tornare alla soluzione precedente equivale a rinunciare
alla commessa ed i livelli superiori della mia società non
l'accetteranno mai perchè il cliente è strategico.
Suggerimenti?
-- 
s/invalid.invalid/
libero.it/
spam -> 
da...@tin.it

 shutdown, ma la risposta è stata del tipo "non se ne parla nemmeno",
In tal caso sono affari loro. Devo supporre che se chi gli fornisce
i macchinari gli dice di lubrificare gli ingranaggi e loro rispondono
"non se ne parla nemmeno", quando la stessa macchina si guasta la
parcella di riparazione la pagano senza protestare no?
Davide

 Suggerimenti?
Fare test su filesystem alternativi? Che so, XFS?
-- 
Cris Carampa (
spamto:cri...@operamail.com
)
"Poveri fanatici comunisti, noglobal e affetti dalla sindrome
anti-microsoft" (gli utenti Linux secondo un poster di ICOD)

 interruttore generale che disenergizza tutto il settore, quindi linea di
Se gli operai invecie di pigiare in un interruttore generale, pigiassero
sul tasto power del pc, potresti abilitare l'acpi, ma se staccano un
generale, la vedo dura.
Ma i pc vengono spenti sempre alla stessa ora? se si (ma ne dubito
fortemente) potresti mettere in cron lo shutdown.
Oppure, provo a buttare un'idea, ma probabilmente e' una cacata:
Per limitare i danni potresti unsare un fylesystem sincrono[1], e
disabilitare l'fsck al boot. Non so quanto possa essere affidabile.
cmq non e' una soluzione affidabile, non e' detto che un database scriva
subito i dati sul disco, potrebbe tenerseli in ram, quindi...
E lasciare i pc sempre accesi? e' impossibile?
cya
Banana
[1] Se non esiste a possibilita' di montare un filesystem sincron,
potresti fare un script che chiama sync ogni secondo o mezzo secondo,
non e' elegante, ma dovrebbe funzionare.

 non e' elegante, ma dovrebbe funzionare.
Dipende dal db: se il db l'asincrono lo fa di suo ci fai poco.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	(Seen on TV!!!)
	"Risparmiamo 5 centesimi a transazione!"


Infatti, era un dubbio che e' venuto anche a me...
Dato che non sono esperto di database, ti chiedo (cosi per culturella
personale) esistono database 'sincroni' e/o configurabili in modoalita
'sincrona'??
ciao
Banana

 Suggerimenti?
Domanda:
questi PC acquisiscono dati dai PLC e li memorizzano
su HD tramite il DB.
Cosa succede a questi dati in seguito?
Voglio dire vengono pescati, riletti, cosa se ne fanno?
Quanto spazio occupano questi dati?
L'idea di avere tutto montato RO non e` affatto male.
Mi chiedevo se potesse essere estesa a tutto...
bye,
-- 
   Piergiorgio Sartor


Postgres se non ricordo male può andare in entrambe le modalità


Daniel Kobza wrote:
...
 > Suggerimenti?
/etc/default/rcS  :
.....
# Set FSCKFIX to "yes" if you want to add "-y" to the fsck at startup.
FSCKFIX=yes
La situazione e` orripilante, ma a mali estremi...
-- 
Vincenzo

Suggerimenti?
   Una di queste? (in ordine di preferenza personale)
   UPS da pochi i minuti su tutti i pc con apmd o altro demone che
lanci lo shutdown appena la batteria comincia a scaricarsi.
   Mettere un cronjob abbastanza frequente che faccia sync.
   Jounalling fs (tipo ext3), quasi tutto cio` che scrive su disco
disabilitato (niente syslog, ecc.) montando read-only tutto quello che
e` possibile.
-- 
S.L.

 Suggerimenti?
Dei dati acquisiti poi cosa ne viene fatto? Dove vengono elaborati? Come
vengono trasferiti?
-- 
"It is not enough to succeed.  Others must fail."
Linux Registered User #301571, running Gentoo
Memeber of Luganega - Linux User Group Crema (IT)
http://filibusta.crema.unimi.it/

 Suggerimenti?
Ricapitolando potrsti fare:
- eliminare syslog e tutto quello che va a scrivere informazioni in piu'
  sul disco.
- Montare il maggior numero di filesystem in ro.
- Per i filesystem che non sono in ro, prevedere un mount sincrono o
  uno script che chiama sync ogni mezzo secondo.
- Impostare il postgress in modalita' sincrona.
- Impostare la risposta "y" automatica a fsck.
- Impostare un cron job che copi il database e tutti i dati importanti
  ogni tot tempo, im modo che se si sputtanano i file che contengono il
  database riesci a ripristinare quelli di 5 min prima, limitando i
  danni.
- Inserire in ogni pc un santino di S. Antonio.
cosi dovresti essere *abbastanza* sicuro, al limite se propio perdi dei
dati importanti, perdi solo pochi minuti di lavoro, dato che c'e' la
copia di riserva fatta dal cronjob.
cya
Banana

 spegnimenti brutali (queste sono parole loro).
Fermo restando i consigli che gia` ti hanno dato, in larga parte
condivisibile, su questa sezione _MENTONO_.
E' dimostrato e dimostrabile.
ps:
se usi ext3, e journali, _NON_ dovrebbe in fsck, visto che il file
system e` consistente. Perche` a te succede? Non stiamo parlando del
fsck maximal mount (da disabilitare), vero?
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
An NT server can be run by an idiot, and usually is.

 fsck maximal mount (da disabilitare), vero?
Non e` proprio esatto.
Al momento del mount di ext3, in caso di problemi,
viene fatto il recovery del journal.
Se pero` vengono trovate incosistenze nel journal
(a volte succede), parte fsck...
bye,
-- 
   Piergiorgio Sartor

 (a volte succede), parte fsck...
Afaik, succedeva solamente su macchine RH 7.3 o AS 2.1 con il kernel
originale, che aveva il supporto a ext3 bacato che ogni tanto sputtanava
il journal.
Per il resto, la corruzione del journal non dovrebbe accadere mai (almeno
per ext3 "standard", se si usa la ext3 con i btree č un altro discorso, ma
lě vuol dire andarsele a cercare).
Almeno, AFAIK...
Se poi qualcuno ha info in piů prego postare...
Hola...
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Skull says:
Stop VeriSign. Go to 
http://www.whois.sc/verisign-dns/
* The most stupid thing since Microsoft Network... <g> *

 Quanto spazio occupano questi dati?
Il sistema acquisice dal PLC l'immagine di una 40ina di registri ogni 30
secondi e ne traccia le variazioni. In funzione dell'andamento
produttivo, si può arrivare a circa 30 tpm, con un occupazione di spazio
tra i 7 e i 15 MB/giorno (del solo DB, esclusi i report prodotti), lo
svecchiamento è bimestrale.
Cmq, per sicurezza ho implementato un wrapper che scrive in un file di
testo (messo in una partizione rw dove c'è solo questo file) qualsiasi
istruzione SQL passata al DB, in modo da avere una sorta di redo log in
formato plain text e processabile come file di spool da psql. Adesso
stiamo valutando la possibilità di eliminare Postgres dai singoli PC e
utilizzare questo file (o qualcosa di simile) per rigenerare le
transazioni su un host "affidabile" che raccoglierà tutti i file
prelevati "manualmente" dai vari PC dall'omino di cui sopra.  Abbiamo
pensato anche ad una generazione "multiplexata" dei file di spool (cioè
tante scritture in parallelo, in modo da avere più file nel caso uno si
corrompa), ma il dubbio è che il maggior overhead aumenti il rischio di
incasinamento del fs. Abbiamo anche pensato di usare una partizione per
file. In ogni caso, alla fine si complicherebbe l'operazione di trasf.
attuata dall'omino (quale dei file è valido e deve essere trasferito?).
L'ostacolo principale è cmq. il cliente, che vuole ogni PC totalmente
autonomo.
Saluti,
Dan


 (a volte succede), parte fsck...
E` vero, ma dovrebbe essere una condizione eccezionale. Almeno con la
forma di journaling "ordered". A quel punto, dovrebbe verificarsi solo
in caso di error on disk. Insomma, io ne ho visti proprio pochi
(tendenti allo zero). E` cosi` sfortunata quella installazione?
Se no, vale la pena di montare il journal in writeback mode?
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
sigfault

 shutdown, ma la risposta è stata del tipo "non se ne parla nemmeno",
Prelevare l' alimentazione dei PC a monte degli interruttori delle linee di
montaggio ?
Che problemi gli vengono dal tenere alimentati i PC con le linee
deenergizzate ?
--------
Sergio Bianchi

 Suggerimenti?
Installa APMD su tutti i PC.
Colleghi TUTTI i cavetti di spegnimento insieme comandati da un'unico
tasto messo IN FIANCO all'interruttore generale.
Prima il tastino dei PC. Aspettano 60 secondi... e poi quello generale.
La spesa è tutta in piattina... e anche se è un'industria Kilometrica sono
50 € al massimo!
Comunque sia... se non volete perdere il cliente e NON VUOLE modifiche
rispetto a prima, mettete nel case di ogni PC un UPS da 300 Watt, sono
piccolissimi e ci stanno! Loro spengono il generale e i PC fanno lo
shutdown dopo qualche minuto.
Degli UPS di questo tipo costano veramente POCHISSIMO, ottima figura con
il cliente... e voi SIETE BELLI SICURI E TRANQUILLI.
Ciao...
Daniele

 Suggerimenti?
  Tutti quelli che ti hanno dato prima del mio arrivo sono giusti e 
corretti ... 
io posso solo aggiungere che se avessi voglia di rischiare stà per
uscire il reiser4 che si basa su transizioni atomiche, quindi in pratica
non dovrebbe essere possibilie corrompere nessun tipo di file anche se
lo spegnimento arriva durante la scrittura.
Pecchato che debba essere rilasciato a gironi o mesi, e che ovviamente
avrà bisogni di un bel periodo di prova.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

spegnimenti brutali (queste sono parole loro).
non mi convince, non ho usato per molto tempo NT4, ma ti assicuro che
lo spegnimento alla brutta non e' gradito neppure da lui.
come minimo ti becchi la richiesta di controllare il fs al riavvio
successivo (che, a dire il vero in effetti si puo' disabilitare), ma,
sempre in base ai ricordi, prima o poi ti si pianta seriamente.
e a quel punto chiami il tecnico. Di buono c'e' che il fattaccio e'
possibile capiti raramente e quindi possa far credere si tratti di un
malfunzionamento dovuto non tanto allo spegnimento brutale, quanto al
"normale" funzionamento di NT.
Con linux la possibilita' che riavvi normalmente e' piu' bassina,
(ovvero e' piu' facile che chieda un intervento manuale anche per cose
di poco conto) anche se, mettendo tutto il possibile in ro+ext3+sync
potresti *forse* cavartela con interventi manuali nella stessa
frequenza (o forse meno) che con NT
... non per demoralizzarti, ma hai a mano 'na bella pesca, specie per
il fatto che arrivati a questo punto, per come la vedo, ogni minimo
problema sara' colpa di linux ... che prima con NT funzionava tutto...
-- 
nebbia

 sul laptop. Lo so, terribile, ma queste erano le specifiche del cliente.
Vabbe`, ma se la corrente viene staccata durante la
scrittura di dati, ammesso che non via siano problemi
con il FS, il DB risulta quantomeno incompleto.
Questo immagino sia accettabile, dato che e` inevitabile.
Quindi, direi, che la soluzione e` usare un FS che non
si incasina, ma semplicemente lascia il file rovinato.
Oppure non usare affatto un FS.
bye,
-- 
   Piergiorgio Sartor

 lě vuol dire andarsele a cercare).
Scusa, ma se il journal viene scritto a meta`?
Se il commit non avviene, non ci sono santi
che tengano, a mio avviso...
bye,
-- 
   Piergiorgio Sartor

 Se no, vale la pena di montare il journal in writeback mode?
Nel caso in questione potrebbe andare bene, anche se
io tendenzialmente eliminerei complentamente il FS.
bye,
-- 
   Piergiorgio Sartor

 lo spegnimento arriva durante la scrittura.
In base a quale magia?
Voglio dire, se non e` scritto, non e` scritto...
Forse, e dico forse, il FS non si corrompe, ma
anche in questo dubiterei...
bye,
-- 
   Piergiorgio Sartor

 che tengano, a mio avviso...
se il commit non avviene, č sufficiente che questo venga effettuato
all'atto del recovery del FS, se le informazioni loggate sono sufficienti.
In caso non fosse possibile, il recovery si occupa del rollback al
precedente stato coerente.
Salvo difetti di implementazione, ovvio...


 che tengano, a mio avviso...
Da quanto ho capito, ll journal può rimanere scritto a metà, ma solo
l'ultima parte.  Il replay verrà fatto con tutti i metadati
(nel journal) precedenti l'ultimo checkpoint.
Si possono perdere gli ultimissimi aggiornamenti alla struttura
del fs, ma non c'è corruzione.
-- 
Lorenzo

 lo spegnimento arriva durante la scrittura.
Questo lo fa anche ext3 di default.
-- 
Lorenzo

 precedente stato coerente.
Ma e` possibile trovare incosistenze, in particolore nei timestamp.
Evento forse raro, ma possibile.
bye,
-- 
   Piergiorgio Sartor

 scritti, non ci sono santi che tengano.
Ma se manca la conferma di avvenuta scrittura, che viene data solo alla 
fine, tutta la scrittura si considera fallita e viene annullata con un 
rollback (questo almeno come teoria generale delle operazioni atomiche).
-- 
Renato Ramonda
_______________________________
Togli TOGLIMI se vuoi scrivermi

 rollback (questo almeno come teoria generale delle operazioni atomiche).
Si, ma non salvi il file, forse salvi il FS, ammesso
che le informazioni siano comunque reperibili.
In particolare potrebbe essere che l'ultimo blocco
da scrivere (in assoluto) sia scritto a meta`, tanto
per fare un esempio al limite.
bye,
-- 
   Piergiorgio Sartor

 che tengano, a mio avviso...
Vale il commit precedente, afaik. La differenza e` solo se e` presente o
meno l'ultima transazione. Ma il fs dovrebbe risultare integro. Come
infatti mi succede.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Company slogan: The Mandatory Beatings Will Continue Until Morale Improves.

 per fare un esempio al limite.
Già, ma il problema notificato è relativo all'fsck forzato, che è
necessario solo se il FS è in stato incoerente.
I files chiessefrega, quello si sa...


 I files chiessefrega, quello si sa...
Riguardo al problema notificato, limitatamente alla
percentuale di successo di ext3, OK.
Relativamente al fatto che un FS possa salvare un
_file_, invece no.
bye,
-- 
   Piergiorgio Sartor

 infatti mi succede.
Assumendo che:
1) esista un precedente
2) l'attuale sia _riconosciuto_ come errato
bye,
-- 
   Piergiorgio Sartor

 del fs, ma non c'è corruzione.
Nessuno garantisce che il journal sia integro, per
qualunque motivo, per esempio perche` viene danneggiato
da una scrittura incompleta, ne` viene garantito che
sia recuperabile e neanche che sia consistente.
Certo, riduce o minimizza la probabilita` di inconsistenza,
ma non la annulla.
E ripeto, una (sola) volta mi e` successo che una
partizione ext3 abbia fatto (dopo un crash) il
recovery del journal ed abbia detto che vi era
un'inconsistenza, lanciando di seguito fsck alla
vecchia maniera.
bye,
-- 
   Piergiorgio Sartor

 2) l'attuale sia _riconosciuto_ come errato
Che dovrebbe essere sempre vero, salvo errori di implementazione.
Oh, capiamoci, esiste una certa percentuale di possibilita` che mentre
viene scritto il journal esso si corrompa, ma _dovrebbe_ essere
infitesimale.
Invece, nel caso di specie, lo si definiva come "normale" il che mi
sembra quantomeno sospetto.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Is your homepage Y2K compliant? Pipe it through "tr 'yY' 'kK'" to make sure.

 sembra quantomeno sospetto.
Beh, questo pare strano anche a me.
bye,
-- 
   Piergiorgio Sartor

 vecchia maniera.
Che tipo di inconsistenza era?
-- 
Lorenzo

 2) l'attuale sia _riconosciuto_ come errato
E` riconosciuto come errato perché partendo dall'inizio del journal
è l'unico che non ha il checkpoint, che decreta il buon esito della
transazione.
-- 
Lorenzo


Invece si, con data=journal :)
-- 
Lorenzo

 Invece si, con data=journal :)
Sempre limitatamente alla percentuale di successo di ext3 :-)
bye,
-- 
piergiorgio

 Che tipo di inconsistenza era?
Non lo so, si e` lamentato, ha fatto fsck, ha pasticciato
con un po' di inode e poi e` ripartito.
Forse, non ricordo esattamente, ha trovato un inode orfano,
ma senza conseguenze serie.
bye,
-- 
piergiorgio

 transazione.
Non puoi saperlo.
Magari ha il checkpoint, ma i dati sono rovinati,
perche` nel momento del trasferimento la memoria
era cosi` cosi`...
bye,
-- 
piergiorgio

 ma senza conseguenze serie.
Gli inode orfani sono normali, nessuna corruzione.
Erano file già rimossi prima del crash ma che erano tenuti
aperti da qualche processo.  La semantica Unix dice che
un file viene effettivamente deallocato quando il numero
dei suoi riferimenti (hard links + fd dei processi) va 0.
Il file non è più visibile, non ha una sua entry nella
directory che lo conteneva, tuttavia è ancora allocato
perché c'è un processo che lo usa.  Dopo il crash il
processo è sicuramente morto.. e per rispettare la
semantica Unix al reboot il file deve essere cancellato
o più precisamente deallocato ed è proprio questo che
fa fsck.
-- 
Lorenzo


ext3 come molti altri fs assume che l'hw funzioni per
la maggior parte del tempo..
Per evitare lo scenario che ipotizzi il fs dovrebbe
fare un checksum SHA1 per ogni blocco che scrive :)
Cmq sarei curioso di vedere un fs simile, completamente
fault tolerant.
-- 
Lorenzo

 Gli inode orfani sono normali, nessuna corruzione.
Ma non era quello il problema, bensi` il fatto che
ha ritenuto necessario far partire fsck.
bye,
-- 
piergiorgio

 fault tolerant.
Non e` semplicemente possibile, a meno di non avere,
come detto altrove, un completo controllo dell'HW.
Addirittura il modo in cui avviene il power fail
deve essere controllato, per esempio non vi devono
essere sbalzi, ma deve andare giu` liscio.
bye,
-- 
piergiorgio

 ha ritenuto necessario far partire fsck.
Forse per pura coincidenza avevi superato il mount count
o era passato troppo tempo dall'ultimo check e il sesto
campo di fstab era != 0.
-- 
Lorenzo


Cosa non vera con i PC :)
-- 
Lorenzo

 campo di fstab era != 0.
Ci ho pensato, ma ha proprio sottolineato che vi era una
inconsistenza nel FS.
D'altro canto e` successo solo una volta...
bye,
-- 
piergiorgio