เหตุใดการอัปเดตระบบ Linux ที่ใช้งานจึงไม่มีปัญหา


25

เป็นเวลาหลายปีที่ฉันใช้ระบบ Linux ทุกวันและฉันไม่เคยมีปัญหาที่สำคัญโดยการอัปเดตระบบเมื่อมันทำงานอยู่ แต่ฉันก็ยังสงสัยว่าทำไมสิ่งนี้ถึงเป็นไปได้

ขอยกตัวอย่าง

สมมติว่าโปรแกรม "A" จากบางแพ็คเกจกำลังทำงานอยู่ในระบบ โปรแกรมนี้จะต้องเปิดไฟล์อื่น ("B") จากแพ็คเกจเดียวกัน หลังจากนั้นโปรแกรม "A" จะปิด "B" เพราะไม่ต้องการอีกต่อไป สมมติว่าตอนนี้ฉันอัปเดตแพ็คเกจ "A" และ "B" "A" ไม่ได้รับผลกระทบโดยตรงจากการดำเนินการนี้อย่างน้อยก็ในขณะนี้เนื่องจากทำงานใน RAM และการอัปเดตจะแทนที่ "A" บนฮาร์ดดิสก์ สมมติว่า "B" ถูกแทนที่บนระบบไฟล์ด้วย ตอนนี้ "A" จำเป็นต้องอ่าน "B" อีกครั้งด้วยเหตุผลบางอย่าง คำถามคือ: เป็นไปได้หรือไม่ที่ "A" อาจพบรุ่น "B" ที่เข้ากันไม่ได้และเกิดความผิดพลาดหรือการทำงานผิดพลาดด้วยวิธีอื่น?

เหตุใดจึงไม่มีใครอัปเดตระบบของพวกเขาโดยการรีบูตด้วย CD สดหรือขั้นตอนที่คล้ายกัน


ฉันมักจะชอบหลีกเลี่ยงการอัปเดตดังกล่าวไม่ใช่เพราะกลไกของการอัปเดต (สามารถทำได้ดี) แต่เนื่องจากการตั้งค่าเพื่อทดสอบแอปพลิเคชันและการกำหนดค่าของฉันกับการเปลี่ยนแปลงครั้งแรก จากนั้นฉันจะมีระบบที่อัปเดตตอนนี้แยกต่างหากเพื่อเปลี่ยนเป็น แต่นอกเหนือจากนั้นการอัพเดทใน userland โดยทั่วไปไม่ใช่ปัญหาและสำหรับการแก้ไขปัญหาความปลอดภัยเล็ก ๆ น้อย ๆ ผมก็แค่ทำ
Skaperen

คำตอบ:


23

การอัพเดต Userland เป็นปัญหาที่เกิดขึ้นไม่บ่อยนัก

คุณสามารถอัปเดตแพ็คเกจในระบบสดได้บ่อยเนื่องจาก:

  1. ไลบรารีที่แบ่งใช้จะถูกเก็บไว้ในหน่วยความจำไม่อ่านจากดิสก์ในการโทรแต่ละครั้งดังนั้นเวอร์ชันเก่าจะยังคงใช้งานอยู่จนกว่าแอปพลิเคชันจะเริ่มต้นใหม่
  2. ไฟล์ที่เปิดนั้นจะอ่านจากตัวอธิบายไฟล์ไม่ใช่ชื่อไฟล์ดังนั้นเนื้อหาไฟล์ยังคงมีอยู่สำหรับแอปพลิเคชั่นที่กำลังทำงานแม้ว่าจะย้าย / เปลี่ยนชื่อ / ลบไปจนกว่าเซกเตอร์นั้นเขียนทับหรือปิดไฟล์
  3. แพคเกจที่ต้องมีการโหลดซ้ำหรือรีสตาร์ทมักจะได้รับการจัดการอย่างถูกต้องโดยผู้จัดการแพคเกจหากแพ็กเกจได้รับการออกแบบมาอย่างดี ตัวอย่างเช่น Debian จะเริ่มบริการบางอย่างเมื่อมีการอัพเกรด libc6

โดยทั่วไปยกเว้นว่าคุณกำลังอัปเดตเคอร์เนลและไม่ได้ใช้ ksplice โปรแกรมหรือบริการอาจต้องรีสตาร์ทเพื่อใช้ประโยชน์จากการอัปเดต อย่างไรก็ตามไม่จำเป็นต้องรีบูตระบบเพื่ออัปเดตสิ่งใด ๆ ใน userland ถึงแม้ว่าบนเดสก์ท็อปมันจะง่ายกว่าการรีสตาร์ทแต่ละบริการ

ดูสิ่งนี้ด้วย

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode


แต่จะเกิดอะไรขึ้นหากคุณต้องการหน่วยความจำแคชทั้งหมด ในกรณีที่หุ้นห้องสมุดจะต้องมีการโหลดอีกครั้งจากดิสก์ ...
นิลส์

3
จริงๆแล้วคำอธิบายของ # 1 ไม่ชัดเจนนัก เนื้อหาไฟล์ไลบรารีเก่ายังคงอยู่ภายใต้ inode (ต้นฉบับ) แยกต่างหากแม้ว่าชื่อทั้งหมดที่เชื่อมโยงไปนั้นจะหายไปตราบใดที่บางกระบวนการเปิดไฟล์หรือเนื้อหาถูกแมปข้อมูลจะถูกเก็บไว้อย่างชัดเจน (และระบบไฟล์ไม่สามารถ ถูกประกอบใหม่ r / o จนกระทั่งการยกเลิกการเชื่อมโยงไฟล์เสร็จสมบูรณ์) กระบวนการที่แม็พไฟล์ต้นฉบับยังคงมีการแม็พหน่วยความจำกับเนื้อหาต้นฉบับ
Skaperen

@ ไม่มีฉันไม่ใช่ผู้เชี่ยวชาญ แต่ถ้าคุณหมดแคชมันจะไม่ถูกเขียนขึ้นเพื่อแลกเปลี่ยนและอ่านซ้ำจากที่นั่น? หากเต็มแล้วอาจมีการปิดกั้นบางกระบวนการก่อนที่จะนำหน่วยความจำออกจากกระบวนการอื่นที่ใช้อยู่แล้ว
โจ

@ Joe no - swap ก็คือ ram เช่นกัน Skaperen อธิบายถึงสิ่งที่เกิดขึ้น: ตัวจัดการไฟล์ถูกเก็บไว้ไม่เปลี่ยนแปลง ดังนั้นโดยทั่วไปโปรแกรมจะมีหนึ่ง hadle ในไลบรารีเก่า (ที่หายไป) ซึ่งจะไม่ถูกลบจนกว่าหมายเลขอ้างอิงนั้นจะว่างอีกครั้ง - ทั้งหมดนี้อยู่ในระดับระบบแฟ้ม - ไม่ใช่ในระดับ RAM
นิลส์

4

ใช่สิ่งที่คุณอธิบายเป็นไปได้ แต่ส่วนใหญ่หากไฟล์รวมอยู่ในแพ็คเกจมันจะเป็นห้องสมุดหรือไฟล์อื่น ๆ ที่อ่านครั้งเดียวครั้งเดียวเท่านั้น (เนื่องจากไม่มีการเปลี่ยนแปลงจึงไม่มีเหตุผลที่จะ อ่านหลาย ๆ ครั้ง) นอกจากนี้หากต้องการไฟล์ในระยะยาวแอปพลิเคชั่นอาจเปิดทิ้งไว้ที่จุดจับไฟล์ซึ่งแม้ว่าจะถูกแทนที่ด้วยระบบไฟล์จริงตัวจัดการไฟล์แบบเปิดจะเปิดเวอร์ชันเก่าไว้

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


ไฟล์ยังคงสามารถอ่านซ้ำได้ว่าเป็น "ที่เก็บข้อมูลสำรอง" หากการทำแผนที่ของไฟล์นั้นไม่มีการเปลี่ยนแปลงในหน่วยความจำ (ซึ่งจะเปลี่ยนการจัดเก็บข้อมูลสำรองเพื่อสลับหากมี) และในสำเนาหน่วยความจำจะถูกยกเลิกเนื่องจากความต้องการใช้งานอื่น ๆ ความทรงจำ แต่นี่จะไม่มีปัญหาเพราะไฟล์ต้นฉบับยังคงเปิดอยู่หรือแมป ไลบรารีทดแทนเป็นไฟล์ใหม่และแตกต่างกันซึ่งกระบวนการเก่าไม่ได้เปิด
Skaperen

1
@Skaperen ฉันสมมติว่าคุณกำลังพูดถึงไฟล์ที่แม็พหน่วยความจำ สิ่งเหล่านี้ไม่ใช่ปัญหาเมื่อทำการอัพเกรดแพ็คเกจ ผู้จัดการแพ็คเกจทั้งหมดสร้างไฟล์ใหม่เพื่อแทนที่ไฟล์เก่าแทนที่จะเขียนทับไฟล์เหล่านั้น ในความเป็นจริงนี่เป็นวิธีเดียวที่จะทำได้เนื่องจากไม่สามารถแก้ไขไฟล์ที่รันได้ แต่สามารถยกเลิกการเชื่อมโยงได้
Patrick

4

สมมติว่า "B" ถูกแทนที่บนระบบไฟล์ด้วย ตอนนี้ "A" จำเป็นต้องอ่าน "B" อีกครั้งด้วยเหตุผลบางอย่าง คำถามคือ: เป็นไปได้หรือไม่ที่ "A" อาจพบรุ่น "B" ที่เข้ากันไม่ได้และเกิดความผิดพลาดหรือการทำงานผิดพลาดด้วยวิธีอื่น?

เป็นไปได้ แต่ไม่น่าเป็นไปได้ในกรณีส่วนใหญ่ ถ้า "B" เป็นไลบรารี่โค้ดปกติแล้วเวอร์ชั่นดั้งเดิมจะไม่ถูกปิด "A" จะใช้ "B" เวอร์ชันเดิมต่อไป หากคุณเรียกใช้ "A" หลังจากการอัปเดตจะใช้ "B" เวอร์ชันใหม่ ในระหว่างการอัพเดตมีความเสี่ยงที่สามารถโหลดเวอร์ชั่นที่เข้ากันไม่ได้ อย่างไรก็ตามเนื่องจากวิธีโหลดรหัสไลบรารีสิ่งนี้จะเป็นปัญหาเฉพาะเมื่อ "A" ต้องการฟังก์ชั่นที่ไม่มีอยู่ในรุ่น "B" ที่โหลด

การเข้ารหัสที่ดีจะช่วยให้อินเทอร์เฟซทำงานเหมือนเดิม ดังนั้นมันจึงไม่สำคัญว่าจะโหลดเวอร์ชันใดมากไปกว่านั้นหากมีการแก้ไขข้อบกพร่องในเวอร์ชันที่ใหม่กว่า

ไฟล์การกำหนดค่าเป็นเรื่องที่แตกต่างกันเล็กน้อย แต่มักจะอ่านในระหว่างการเริ่มต้น ในกรณีนี้ "A" จะไม่อ่าน "B" ยกเว้นว่ามีการโหลดการกำหนดค่าใหม่ อีกครั้งจะเป็นการฝึกเขียนโค้ดที่ไม่ดีเพื่อเปลี่ยนรูปแบบหรือความหมายของไฟล์กำหนดค่า ไฟล์คอนฟิกูเรชันเวอร์ชันที่เข้ากันไม่ได้ควรมีชื่อแตกต่างกันดังนั้นจึงไม่ทำให้เกิดปัญหา

เหตุใดจึงไม่มีใครอัปเดตระบบของพวกเขาโดยการรีบูตด้วย CD สดหรือขั้นตอนที่คล้ายกัน

การปิดและรีบูตเครื่องจากเวอร์ชั่นอื่นอาจทำให้บริการขัดข้อง สำหรับเซิร์ฟเวอร์มักไม่ต้องการสิ่งนี้ ไม่ว่าในกรณีใดตัวจัดการแพ็กเกจบนระบบที่รันอยู่จะรับรู้ถึงซอฟต์แวร์และเวอร์ชันที่ติดตั้งไว้ Live CD มีรายการซอฟต์แวร์ที่ติดตั้งเป็นของตัวเอง สิ่งนี้ทำให้ยากต่อการอัพเกรดระบบการเรียกใช้จาก CD สด

บางครั้ง Live CD จะใช้เมื่อมีการติดตั้ง O / S รุ่นใหม่ ในกรณีนี้การติดตั้งแบบ O / S แบบปกติจะเสร็จสิ้น สิ่งนี้สามารถ จำกัด จำนวนไฟล์ที่ไม่ได้ใช้จากเวอร์ชันก่อนหน้าที่ยังคงอยู่ มันอาจเป็นความพยายามมากกว่าการอัพเกรดระบบจริง อย่างไรก็ตามหากใช้พาร์ติชันรูทที่แตกต่างกันก็สามารถจำกัดความเสี่ยงที่จะติดอยู่กับระบบที่ได้รับการอัพเดตบางส่วน


0

มีบางกรณีที่ปัญหานี้เกิดขึ้น:

  • การอัพเกรด JDK ในขณะที่ java-VM กำลังทำงานอยู่: ฉันถาม myselv กับคำถามเดียวกันกับที่คุณได้รับ - ฉันมี tomcat ที่กำลังทำงานซึ่งใช้ java ตอนนี้หลังจากอัพเดตแพตช์ของ JDK มันยังคงทำงานได้โดยไม่มีปัญหา - ดังนั้นจึงดูเหมือน

ตอนนี้คำอธิบายคือหน่วยความจำแคช ตกลง - ฉันเริ่มโปรแกรม memory-hog-program เพื่อใช้ RAM ที่มีอยู่ทั้งหมด - จากนั้น tomcat crashed (หลังจากที่ฉันเข้าถึงแอปพลิเคชันที่ทำงานอยู่ที่นั่น)

  • Kernel-Upgrade บน SuSE-systems: บน SuSE เคอร์เนลเก่าและโมดูลของมันจะถูกลบทันทีหลังจากการอัพเกรดแพทช์ของเคอร์เนล หากคุณต้องการใช้สิ่งใหม่ที่ต้องใช้เคอร์เนลโมดูลที่ไม่ได้โหลดจนถึงตอนนี้บริการจะล้มเหลว

2
ฟังดูคล้ายกับชิ้นส่วนของ Tomcat เริ่มต้นใหม่หรือมีการใช้ไลบรารีแบบไดนามิกด้านล่างระดับ Java (เช่น dlopen () และอื่น ๆ ) ซึ่งอาจจบลงด้วยการผสมผสานของ API แบบสด
Skaperen

@Skaperen แม้เมื่อใช้ห้องสมุดสาธารณะ - ถ้าพวกเขาได้รับหลังจากปิดการใช้งานโปรแกรมใด ๆ ควรจะมีปัญหาถ้าแคชจะได้รับเบาบาง ...
นิลส์

1
ตัวอธิบายไฟล์แบบเปิดมีกำลังงานเดียวกันกับที่เก็บข้อมูลบนดิสก์เป็นชื่อไฟล์ในไดเรกทอรี ไอโหนดเดิมจะไม่ถูกลบตราบใดที่มีฮาร์ดลิงก์บนดิสก์หรือตัวอธิบายไฟล์ที่เปิดอยู่ แคชไม่มีอะไรเกี่ยวข้องกับมัน ตอนนี้บางโปรแกรมปิดอธิบายไฟล์ของพวกเขาเมื่อพวกเขาจะไม่ใช้พวกเขาและที่สามารถให้ข้อมูลที่หายไป
dmckee

@dmckee ถูกต้อง เราใกล้จะถึงแกนแล้ว ดังนั้นสิ่งที่เป็นปกติสำหรับโปรแกรม "ปกติ": เปิดไลบรารี่และเปิดมันไว้หรือโหลดไลบรารี่แล้วปิดมันทีหลัง?
นิลส์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.