Score:10

ฉันจะทำให้ Linux รีบูตแทนการเมานต์ระบบไฟล์ใหม่เป็นแบบอ่านอย่างเดียวได้อย่างไร

ธง us

ระบบ Linux ในบางครั้งจะติดตั้งระบบไฟล์รูทใหม่เป็นแบบอ่านอย่างเดียว เช่น หากมีข้อผิดพลาด I/O

ฉันมีเครื่องที่ไร้ประโยชน์เมื่อสิ่งนี้เกิดขึ้น และฉันลงเอยด้วยการรีบูตเครื่องด้วยตนเอง

มีวิธีทำให้ Linux รีบูตโดยอัตโนมัติเมื่อสิ่งนี้เกิดขึ้นหรือไม่? การเมานต์แบบอ่านอย่างเดียวไม่มีประโยชน์สำหรับฉัน

br flag
ฉันจะตรวจสอบแหล่งที่มาของข้อผิดพลาด I/O เหล่านี้ด้วยครั้งสุดท้ายที่ระบบไฟล์ ext2 ทำงานแบบอ่านอย่างเดียวสำหรับฉันคือในปี 1994 และสาเหตุอาจโยงไปถึงพัดลม CPU ที่เสีย
mx flag
คุณมี [ปัญหา XY](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) ที่นี่ วิธีแก้ไขที่ถูกต้องคือไม่ให้ระบบรีบูตเมื่อเกิดข้อผิดพลาด IO (คำตอบที่ยอมรับจะอธิบายวิธีการดำเนินการดังกล่าว _แต่_จริง ๆ แล้วค่อนข้างเสี่ยงด้วยเหตุผลหลายประการ) ก็คือการ_แก้ไขสาเหตุของข้อผิดพลาด IO_ เนื่องจากระบบไฟล์จะไม่สุ่มเมานต์แบบอ่านอย่างเดียว หากเป็นเพียงช่วงๆ หนึ่งและอุปกรณ์จัดเก็บข้อมูลยังใช้งานได้ดี คุณอาจสงสัยว่า RAM หรือ PSU ไม่เสถียร ซึ่งทั้งสองอย่างนี้อาจทำให้เกิดปัญหาที่ใหญ่กว่าข้อผิดพลาดของระบบไฟล์ทั่วไป
us flag
@AustinHemmelgarn: ฉันไม่มีปัญหา XY ที่นี่ คุณแค่ตั้งสมมติฐานมากมายที่ไม่ถือเป็นจริงในกรณีที่ฉันถามถึง
us flag
@SimonRichter: ฉันได้พยายามหาสาเหตุแล้ว แต่ขอบคุณสำหรับการเตือนความจำ คนอื่นน่าจะทำอย่างนั้นก่อนที่จะรีบูต
us flag
ฉันเพิ่งรู้ว่าฉันโพสต์สิ่งนี้บน ServerFault แทนที่จะเป็น Unix.SE อย่างที่ฉันตั้งใจไว้! ดีใจที่มันยังอยู่ในหัวข้อที่ฉันเดา แต่อย่าลังเลที่จะย้ายข้อมูลหากจำเป็น
cn flag
การรีบูตเครื่องแทนที่จะระบุสาเหตุของการรีเมาต์ R/O มีโอกาสสูงที่จะทำให้ปัญหา *แย่ลง* โดยเฉพาะอย่างยิ่งหากไม่สามารถเมานต์ระบบเมื่อรีบูต และตอนนี้คุณติดอยู่ที่ระบบที่ไม่ตอบสนองโดยสิ้นเชิง
mx flag
@ user541686 คุณมีข้อผิดพลาด IO แบบสุ่ม _will_ นั้นทำให้เกิดปัญหาอื่น ๆ ในที่สุด (และเชื่อฉันเถอะว่าพวกเขาจะเจ็บปวดมากกว่าที่จะแก้ไขมากกว่าแค่รีบูตระบบ) ดังนั้นฉันจึงยืนยันว่านี่เป็นปัญหา XY การที่คุณไม่รู้จัก X เป็นปัญหาไม่ได้ทำให้ปัญหา XY น้อยลงแต่อย่างใด
us flag
@AustinHemmelgarn: ฉันทราบดีถึงสิ่งที่เกิดขึ้นในสถานการณ์ของฉันและเหตุใดฉันจึงใช้วิธีแก้ไขปัญหานี้ น่าเสียดายที่คุณไม่ได้ การที่คุณไม่รู้ว่าคุณยังคงตั้งสมมติฐานที่ไม่มีมูลความจริงเกี่ยวกับสถานการณ์ของฉันไม่ได้ทำให้คุณถูกต้องมากขึ้น แต่เป็นที่ยอมรับว่าฉันไม่สามารถหยุดคุณจากการบรรยายได้
us flag
@Shadur: ฉันเข้าใจทั้งหมดนั้น เชื่อหรือไม่ ไม่มีใครบอกว่าโซลูชันนี้ควรใช้ในทุกสถานการณ์ ฉันแค่บอกคุณว่าฉันมี **a** สถานการณ์ที่โซลูชันนี้สมเหตุสมผล หากคุณนึกไม่ออกว่าทำไมก็ไม่เป็นไร แค่เชื่อในตัวฉันว่าฉันไม่ได้โง่ และฉันแค่ถามเรื่องนี้เพราะมีข้อมูลที่ฉันมี แต่คุณไม่มี
Mark avatar
tz flag
@user541686 หากมีข้อมูลที่เกี่ยวข้อง โปรดระบุ อย่าเพิ่งพูดว่า "เชื่อฉัน"
us flag
@Mark: ไม่ ฉันจะไม่ให้ข้อมูลที่ไม่เกี่ยวข้อง มันค่อนข้างไม่มีใครสนใจว่าสถานการณ์ที่ฉันกำลังเผชิญอยู่นั้นทำให้เกิดคำถามนี้ขึ้น ถ้าคุณอยากจะเชื่อว่ามันเกิดจากความโง่เขลาของฉัน ก็อย่าลังเลที่จะเชื่ออย่างนั้นต่อไป ไม่รู้สึกผูกพันที่จะต้อง "เชื่อฉัน" ไม่ใช่ว่าฉันบังคับคุณได้
Andrew Henle avatar
ph flag
@ user541686 คุณกำลังรายงานข้อผิดพลาด I/O บนระบบไฟล์รูทด้วยการรีบูต บน ***HOPE*** ที่ระบบของคุณจะกลับสู่สถานะการทำงาน คุณกำลังเจอคนที่คิดว่าพวกเขารู้ทุกอย่าง แต่ในความเป็นจริงแล้วฉลาดพอที่จะเป็นอันตราย คุณอาจคิดว่าคุณรู้ว่าทำไมคุณถึงได้รับข้อผิดพลาด IO แต่จะเกิดอะไรขึ้น **เมื่อ** คุณได้รับข้อผิดพลาดที่ไม่เหมือนกับที่คุณคิด คุณได้รับระบบที่ตายแล้วซึ่งคุณไม่สามารถเข้าถึงได้ “ฉันรู้ว่าเกิดอะไรขึ้น!” ไม่มีข้อจำกัดว่า **ทำได้** อย่างไร จักรวาลไม่สนใจสิ่งที่คุณคิดว่าคุณรู้
marcelm avatar
ng flag
@Mark (และคนอื่นๆ) _"... ถ้ามีข้อมูลที่เกี่ยวข้อง ให้ข้อมูลมา อย่าเอาแต่พูดว่าเชื่อฉัน"_ - ฉันไม่คิดว่ามันคุ้มที่จะเห่าต้นไม้ XY ที่นี่ ก่อนอื่น คำถามตามที่เป็นอยู่ (ตื่นตระหนก/รีบูตแทนการเมานต์ ro ใหม่) เป็นคำถามที่ถูกต้องและตอบได้อย่างสมบูรณ์ ประการที่สอง OP ดูเหมือนจะตระหนักดีว่าข้อผิดพลาดของ I/O นั้น อะแฮ่ม ไม่เหมาะ และตอนนี้ได้ประกาศอย่างชัดเจนว่าพื้นที่นั้นอยู่นอกหัวข้อ น่าเศร้าที่บางครั้งไม่มีอะไรที่คุณสามารถทำได้เพื่อแก้ไขสาเหตุที่แท้จริง _right now_ และจำเป็นต้องมีวิธีแก้ปัญหา เมื่อคำนึงถึงสิ่งนี้แล้ว ฉันไม่คิดว่าเราอยู่ในจุดที่ต้องการให้ OP ให้บริบทเพิ่มเติม
Score:23
ธง ca

ฉันอนุมานได้ว่าคุณกำลังใช้ ต่อ 3 หรือ ต่อ4 เป็นระบบไฟล์ ถ้าเป็นเช่นนั้น คุณสามารถติดตั้งกับ ข้อผิดพลาด = ตื่นตระหนก ตัวเลือก และ กำหนดค่า สุนัขเฝ้าบ้าน เพื่อรีบูตระบบของคุณในกรณีที่เกิดความตื่นตระหนก

ในขณะที่ซับซ้อนกว่า คำตอบของ roelvanmeer (ซึ่งฉันโหวตแล้ว) มันมีโบนัสเพิ่มเติมสำหรับการทำงานสำหรับความผิดพลาดของเคอร์เนลระดับตื่นตระหนกทั้งหมด

เนื่องจาก แนะนำโดย NikitaKipriyanovการตั้งค่า ตื่นตระหนก=5 ตัวเลือกการบูตเคอร์เนลอาจเป็นทางเลือกที่ง่ายกว่า สุนัขเฝ้าบ้าน (ซึ่งมีตัวเลือกการกำหนดค่ามากกว่า แต่ผลลัพธ์จะซับซ้อนกว่าเล็กน้อย)

Nikita Kipriyanov avatar
za flag
ทางเลือกอื่นสำหรับ watchdog อาจเพิ่มบางอย่างเช่น `kernel.panic = 5` ลงใน `/etc/sysctl.d/panic-reboot.conf`
us flag
ขอขอบคุณ! ฉันจะให้นี้ยิง หวังว่ามันจะไม่[ล้มเหลวในการรีบูต](https://forums.debian.net//viewtopic.php?f=5&t=102033)!
shodanshok avatar
ca flag
@NikitaKipriyanov คำแนะนำที่ดี ฉันจะแก้ไขคำตอบของฉัน ขอบคุณ.
joshudson avatar
cn flag
คำเตือน: ลูปรีบูตที่น่าจะเป็น
us flag
@joshudson: ใช่ ฉันกำลังวางแผนที่จะระวังเรื่องนั้น นั่นเป็นคำเตือนที่สำคัญสำหรับใครก็ตามที่พยายามทำสิ่งนี้
Andrew Henle avatar
ph flag
@joshudson ถ้ามันรีบูตเลย การพึ่งพาระบบที่รู้ว่าระบบไฟล์รูทของมันอาจเสียหายและ/หรือดิสก์รูทของมันเสียหายเมื่อต้องรีบูตนั้นขึ้นอยู่กับความคิดเพ้อฝันและยูนิคอร์น
joshudson avatar
cn flag
@AndrewHenle: ฉันได้นำระบบจำนวนมากขึ้นมาด้วยระบบไฟล์รูทที่ถูกทิ้ง โดยปกติแล้วฉันไม่สามารถรับช่วงต่อกระบวนการบู๊ตและเรียกใช้ fsck ได้เนื่องจากความเสียหายแทบจะไม่ถึง `/sbin` หรือไฟล์ที่ไม่มีการเปลี่ยนแปลงในชั่วขณะหนึ่ง
Andrew Henle avatar
ph flag
@joshudson คุณหวังว่า ... ;-) ความคิดของฉันที่นี่ขึ้นอยู่กับแนวคิดที่ว่าการพยายามทหารเมื่ออุปกรณ์ระบบไฟล์รูทของคุณกำลังโยนข้อผิดพลาด IO นั้นเป็นความพยายามที่เข้าใจผิดในตอนแรกและการรีบูตทำให้ปัญหาสำคัญมากขึ้นเท่านั้น มีแนวโน้มว่า - "อุปกรณ์รูทของฉันกำลังแย่ ดังนั้นเรามาทำอะไรที่ *** จริง ๆ *** ขึ้นอยู่กับอุปกรณ์รูทที่ทำงานอย่างสมบูรณ์และมีสิทธิ์เข้าถึงระบบไฟล์จำนวนมากอย่างเหมาะสม!"
Score:14
ธง ie

อาจไม่ใช่วิธีแก้ปัญหาที่สวยงามนัก แต่ความคิดแรกของฉันคือการเรียกใช้คำสั่งจาก cron ทุกนาที:

ทดสอบ -w / || รีบูต
us flag
+1 ขอบคุณ นี่จะเป็นทางเลือกที่ดีหากโซลูชันอื่นล้มเหลว!
ฉันคิดว่าไม่รับประกันว่า `test -w` จะตรวจสอบว่าระบบไฟล์เป็นแบบอ่าน-เขียนหรือไม่ แม้ว่า GNU `test` และ `test` ที่สร้างขึ้นใน `bash` ดูเหมือนจะทำเช่นนั้น --- ที่นี่ คุณสามารถดูสิ่งที่ควรปฏิบัติตาม POSIX `ทดสอบ': https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html#tag_20_128_05 ตามที่ฉันเข้าใจ `test` จำเป็นต้องตรวจสอบเท่านั้น สิทธิ์การเข้าถึงไฟล์
joshudson avatar
cn flag
ซึ่งในกรณีนี้ `tee -a /root/.bash_history
shodanshok avatar
ca flag
@joshudson ง่ายกว่า: `สัมผัส /writecheck || รีบูต '
br flag
@shodanshok ดีมากถ้าคุณไม่รังเกียจไฟล์ชื่อ `/writecheck` ที่รูทของระบบไฟล์ของคุณ เนื่องจากไฟล์จะถูกสร้างขึ้นเมื่อระบบไฟล์ _isn't_ อ่านอย่างเดียว วิธีการอื่นๆ ที่เสนอคือพยายามหลีกเลี่ยงการสร้างไฟล์เปล่าปลอม (แม้ว่า pabouk จะพูดถูก â ซึ่งฉัน 50/50 ก็ตาม โดยส่วนตัวแล้ว â จริงๆ แล้วการสร้างไฟล์อาจเป็นสิ่งที่หลีกเลี่ยงไม่ได้ เพื่อกำหนดสถานะอ่านอย่างเดียวของระบบไฟล์อย่างสมบูรณ์)
คำถามอื่นเกี่ยวกับปัญหาในการทดสอบการเข้าถึงเพื่อเขียน: [วิธีทดสอบการเข้าถึงเพื่อเขียนไฟล์แบบไม่รุกรานได้อย่างไร](https://unix.stackexchange.com/q/159557/19702)
cn flag
@shodanshok ที่อาจนำไปสู่การรีบูตโดยไม่คาดคิด - หรือรีบูตลูป - จากเงื่อนไขข้อผิดพลาดที่ไม่เกี่ยวข้องกับข้อผิดพลาดของระบบไฟล์ เช่น การติดตั้ง libc ขัดข้องชั่วคราว เงื่อนไข OOM อะไรก็ตามที่อาจทำให้สัมผัสล้มเหลว....
shodanshok avatar
ca flag
@rackandboneman แน่นอน - แต่สคริปต์ *ใดๆ* ที่มี `|| reboot` อยู่ภายใต้ปัญหาเหล่านี้ ยิ่งไปกว่านั้น ถ้า `touch` ล้มเหลวในระบบของคุณเนื่องจากปัญหา libc คุณอาจมีปัญหาที่แย่กว่านั้นคือการวนรอบการรีบูต อย่างไรก็ตาม ตามที่ระบุไว้ในคำตอบของฉัน 'สุนัขเฝ้าบ้าน' เป็นหนทางสู่ความต้องการขั้นสูง

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา