Puncte:10

Cum pot face să repornesc Linux în loc să remontez sistemul de fișiere ca doar pentru citire?

drapel us

Sistemele Linux remontează uneori sistemul de fișiere rădăcină ca doar citire, de ex. dacă există o eroare I/O.

Am o mașină care devine inutilă când se întâmplă acest lucru și ajung să o repornesc manual.

Există vreo modalitate de a face Linux să repornească automat când se întâmplă acest lucru? O montură numai pentru citire îmi este inutilă.

drapel br
De asemenea, aș investiga sursa acestor erori I/O.Ultima dată când un sistem de fișiere ext2 a mers doar în citire pentru mine a fost în 1994, iar cauza ar putea fi urmărită la un ventilator defect al procesorului.
drapel mx
Aveți o [problema XY](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) aici. Soluția corectă este să nu faceți repornirea sistemului la o eroare IO (răspunsul acceptat explică cum să faceți asta, _dar_ asta este de fapt destul de riscant din mai multe motive), ci să _remediați cauza principală a erorilor IO_ , pentru că atunci sistemul de fișiere nu va fi montat aleatoriu doar în citire. Dacă este doar intermitentă și dispozitivul de stocare este bun, probabil că aveți RAM suspectă sau un PSU defectuos, ambele pot provoca probleme mult mai mari decât o simplă eroare a sistemului de fișiere.
drapel us
@AustinHemmelgarn: Nu am o problemă XY aici. Faci doar o mulțime de presupuneri care nu sunt adevărate în cazul (cazurile) despre care întreb.
drapel us
@SimonRichter: Într-adevăr, am încercat să cercetez cauza, dar mulțumesc pentru memento, probabil că alții ar trebui să facă asta înainte de a reporni.
drapel us
Tocmai mi-am dat seama cumva că am postat asta pe ServerFault, mai degrabă decât pe Unix.SE, așa cum am vrut! Mă bucur că este încă la subiect, cred, dar nu ezitați să migrați dacă este necesar.
drapel cn
Repornirea, mai degrabă decât rezolvarea motivului remontării R/O, are o probabilitate mare de a înrăutăți problema* - mai ales dacă nu reușește să monteze sistemul la repornire și acum ești blocat cu un sistem complet care nu răspunde.
drapel mx
@user541686 Aveți erori aleatoare de IO. Acest lucru _va_ cauza în cele din urmă alte probleme (și crede-mă, vor fi mult mai dificil de rezolvat decât doar repornirea sistemului), de unde afirmația mea că aceasta este o problemă XY. Faptul că nu recunoașteți X-ul ca o problemă nu îl face mai puțin o problemă XY.
drapel us
@AustinHemmelgarn: Sunt foarte conștient de ce se întâmplă în situația mea și de ce am apelat la această soluție. Din păcate nu ești. Faptul că nu recunoașteți că încă faceți presupuneri nefondate cu privire la situația mea nu vă face mai corect, dar, desigur, nu vă pot împiedica să predați.
drapel us
@Shadur: Înțeleg pe deplin toate astea, crezi sau nu. Nimeni nu spune că această soluție ar trebui folosită în orice situație. Vă spun doar că am **o** situație în care această soluție are sens. Dacă nu vă puteți imagina de ce, este în regulă. Ai doar încredere în mine că nu sunt prost și că întreb asta doar pentru că am informații pe care tu nu le ai.
Mark avatar
drapel tz
@user541686, dacă există informații relevante, furnizați-o. Nu spune doar „ai încredere în mine”.
drapel us
@Mark: Nu, nu voi oferi informații irelevante. Nu este treaba nimănui cu ce situație mă confrunt și care a dat naștere la această întrebare. Dacă preferați să credeți că este din prostia mea, nu ezitați să continuați să credeți asta; nu te simti obligat sa "increzi in mine". Nu e ca și cum te-aș putea forța.
Andrew Henle avatar
drapel ph
@user541686 Înregistrați erorile I/O de pe sistemul de fișiere rădăcină cu o repornire, cu ***SPERAnța*** că sistemul dumneavoastră va reveni la starea operațională. Vii ca cineva care crede că știe totul, dar în realitate este suficient de inteligent pentru a fi periculos. Poate credeți că știți de ce primiți erori IO, dar ce se întâmplă **când** primiți una care nu este așa cum credeți? Obțineți un sistem mort pe care nu îl puteți accesa. „Știu ce se întâmplă!” nu oferă nicio limită cu privire la ceea ce **poate** să continue - universului nu-i pasă de ceea ce crezi că știi.
marcelm avatar
drapel ng
@Mark (și alții) _"... dacă există informații relevante, furnizați-o. Nu spune doar ai încredere în mine."_ - Nu cred că merită să lătrăm arborele XY aici. În primul rând, întrebarea așa cum este (panică/reboot în loc de remontare ro) este o întrebare perfect validă și la care se poate răspunde. În al doilea rând, OP pare să știe bine că erorile I/O nu sunt, ahem, ideale și acum a declarat în mod explicit acea zonă în afara subiectului. Din păcate, uneori nu poți face nimic pentru a remedia cauza principală _chiar acum_ și este nevoie de o soluție. Având în vedere asta, nu cred că suntem într-un loc în care să cerem că OP oferă mai mult context.
Puncte:23
drapel ca

Deduc că folosești ext3 sau ext4 ca sistem de fișiere. Dacă da, îl puteți monta cu erori=panica opțiune și configurați câine de pază pentru a reporni sistemul în caz de panică.

Deși mai complex decât răspunsul lui Roelvanmeer (pe care l-am votat pozitiv), are avantajul suplimentar de a funcționa pentru toate erorile de kernel la nivel de panică.

La fel de sugerat de NikitaKipriyanov, setarea panica=5 Opțiunea de pornire a nucleului poate fi o alternativă mai simplă la câine de pază (care are mai multe opțiuni de configurare, dar este puțin mai complex ca rezultat).

Nikita Kipriyanov avatar
drapel za
Alternativa la watchdog ar putea fi adăugarea a ceva de genul `kernel.panic = 5` în `/etc/sysctl.d/panic-reboot.conf`.
drapel us
Mulțumesc! O să încerc asta. Să sperăm că nu va [reporni](https://forums.debian.net//viewtopic.php?f=5&t=102033)!
shodanshok avatar
drapel ca
@NikitaKipriyanov bună sugestie, îmi voi edita răspunsul. Mulțumiri.
joshudson avatar
drapel cn
avertisment: buclă probabilă de repornire
drapel us
@joshudson: Da, plănuiesc să fiu atent la asta, acesta este cu siguranță un avertisment important pentru oricine încearcă asta.
Andrew Henle avatar
drapel ph
@joshudson Dacă se repornește deloc. Bazându-vă pe un sistem care știe că sistemul său de fișiere rădăcină ar putea fi corupt și/sau discul rădăcină rupt pentru a reporni se bazează pe dorințe și unicorni.
joshudson avatar
drapel cn
@AndrewHenle: Am adus o mulțime de sisteme cu un sistem de fișiere rădăcină rădăcină. De obicei, nu pot prelua procesul de pornire și pot face fsck să ruleze, deoarece daunele lovesc rar `/sbin` sau fișierele care nu s-au schimbat de ceva timp.
Andrew Henle avatar
drapel ph
@joshudson Sperați... ;-) Gândurile mele aici se bazează pe ideea că încercarea de a lupta când dispozitivul dvs. de sistem de fișiere rădăcină aruncă erori IO este un efort greșit, în primul rând, iar repornirea face doar probleme semnificative mai mult probabil - „Dispozitivul meu rădăcină merge prost, așa că haideți să facem ceva care ***într-adevăr*** depinde de funcționarea completă a dispozitivului rădăcină și de acces adecvat la cea mai mare parte a sistemului de fișiere!”
Puncte:14
drapel ie

Poate că nu este o soluție foarte frumoasă, dar primul meu gând ar fi să rulez o comandă de la cron în fiecare minut:

test -w / || reporniți
drapel us
+1 Mulțumesc, aceasta va fi o soluție excelentă dacă cealaltă soluție nu reușește!
drapel im
Cred că nu este garantat că `test -w` verifică dacă sistemul de fișiere este de citire-scriere. Deși `test` și `test` GNU încorporate în `bash` par să facă asta. --- Aici puteți vedea ce ar trebui să facă `testul` compatibil cu POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html#tag_20_128_05 După cum am înțeles, `testul` este necesar doar pentru a verifica drepturile de acces la fișier.
joshudson avatar
drapel cn
În acest caz `tee -a /root/.bash_history
shodanshok avatar
drapel ca
@joshudson Și mai simplu: `touch /writecheck || repornire`
drapel br
@shodanshok Este grozav dacă nu vă deranjează un fișier numit `/writecheck` care se află la rădăcina sistemului dvs. de fișiere, deoarece va fi creat atunci când sistemul de fișiere _nu_ este doar pentru citire. Celelalte metode propuse încercau să evite crearea oricăror fișiere goale false. (Deși dacă pabouk are dreptate – pe care eu sunt 50/50, personal – crearea efectivă a unui fișier poate fi inevitabil, pentru a determina pe deplin starea de numai citire a sistemului de fișiere.)
drapel im
O altă întrebare despre problema testării accesului la scriere: [Cum se testează în mod neinvaziv accesul la scriere la un fișier?](https://unix.stackexchange.com/q/159557/19702)
drapel cn
@shodanshok care ar putea duce la reporniri neașteptate - sau bucle de repornire - din condiții de eroare care nu au legătură cu erorile sistemului de fișiere, de exemplu, întreruperi temporare ale instalării libc, condiții OOM, orice ar putea face atingerea să eșueze...
shodanshok avatar
drapel ca
@rackandboneman sigur - dar *orice* script cu `|| reboot` este supus acestor probleme. Mai mult, dacă `touch` eșuează pe sistemul dvs. din cauza problemelor libc, probabil că aveți o problemă mai gravă decât o buclă de repornire. Oricum, așa cum am spus în răspunsul meu, „câinele de pază” este calea de urmat pentru nevoi mai avansate.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.