ฉันจะแน่ใจได้อย่างไรว่างาน Upstart หนึ่งงานเริ่มต้นก่อนงาน Upstart อื่น ๆ ?

นี่เป็นคำถามธรรมดาทั่วไป แต่ให้ฉันใช้กรณีเฉพาะ:

Centrify เป็นเกตเวย์ NIS ถึง ActiveDirectory มันต้องโหลดก่อนบริการใด ๆ ที่จะขึ้นอยู่กับบริการการตรวจสอบความถูกต้องที่มีให้เช่น autofs, cron, nis, et al

สิ่งนี้พิสูจน์แล้วว่าเป็นสิ่งที่ท้าทายที่จะประสบความสำเร็จแม้ว่าจะพยายามเปลี่ยนการพึ่งพาของบริการอื่น ๆ (ซึ่งฉันไม่คิดว่าเราควรจะทำต่อไป .

ข้อเสนอแนะ?

boot upstart init

— มาร์ครัสเซล
แหล่งที่มา

คำตอบ:

วิธีการแก้ปัญหาคือการเข้าถึงปัญหาจากทิศทางอื่น ๆ : เพื่อให้เป็นไปตามเกณฑ์การเริ่มต้นของ Centrify ไม่จำเป็นต้องให้บริการที่มีอยู่ขึ้นอยู่กับบริการ Centrify ใหม่ แต่ให้บริการ Centrify ใหม่ขึ้นอยู่กับบริการที่มีอยู่

ตัวอย่างเช่นไฟล์คอนฟิกูเรชัน Upstart /etc/init/centrify.confสามารถพูดได้:

เริ่มต้น (เริ่ม cron หรือเริ่ม autof หรือเริ่มต้น nis)

การแปลงเป็นภาษาอังกฤษสิ่งนี้จะแปลเป็น:

เริ่มต้นบริการ Centrify ก่อน cron, autofs หรือ nis start (ใดก็ตามที่เริ่มก่อน)

ลำดับที่ cron, autofs หรือ nis start นั้นไม่เกี่ยวข้อง: การพุ่งพรวดจะทำให้แน่ใจว่า Centrify จะเริ่มก่อนบริการใดก็ตามที่เริ่มก่อนดังนั้นจึงมั่นใจได้ว่า Centrify ทำงานก่อนที่จะเริ่มบริการใดบริการหนึ่ง

โปรดทราบด้วยเช่นกันว่า Upstart จะบล็อกการเริ่มต้นของบริการแรกที่ต้องการเริ่มจนกว่า Centrify เริ่มทำงาน

สง่างามและเรียบง่ายเมื่อคุณคุ้นเคยกับการคิดในลักษณะนี้

— เจมส์ฮันท์
แหล่งที่มา

ดูเหมือนว่าจะย้อนกลับไปโดยสิ้นเชิงกับฉัน จึงควรสคริปต์ conf สำหรับการให้บริการอย่างใดอย่างหนึ่งได้รับการแก้ไขเมื่อสิ่งอื่น ๆ ขึ้นอยู่กับมัน ?

— ben w

@benw เพื่อให้คุณไม่ต้องแก้ไขการตั้งค่าบริการที่คุณไม่ได้เป็นเจ้าของ

— Paccc

@Paccc เมื่อฉันเขียนสคริปต์ใหม่ที่ขึ้นอยู่กับ nginx ฉันต้องแก้ไขสคริปต์ conf สำหรับ nginx ... ซึ่งฉันไม่ได้เป็นเจ้าของ

— เบน W

@benw ทำไมคุณไม่สามารถใช้start on (started nginx)สคริปต์ใหม่ของคุณ?

— Paccc

@Paccc ไม่ได้จริงๆ start on (started nginx)หมายถึง "เริ่มบริการของฉันหลังจาก nginx" ซึ่งไม่เหมือนกับ "start nginx ก่อนบริการของฉันเพราะมันต้องการ"

— sickill

คำตอบของ James ทำงานได้สำหรับการพึ่งพา 1 ต่อ 1 สำหรับ 1 ถึงมากคือเพื่อให้แน่ใจว่าบริการ A เริ่มก่อนบริการ B, C และ D คุณต้องใช้แนวทางอื่น คุณสามารถดูสคริปต์ portmap ปัจจุบันสำหรับการอ้างอิง แต่นี่คือวิธีการทั่วไป: สร้างสคริปต์รอ

สถานการณ์: คุณต้องการบริการของคุณ A จะเสมอทำงานก่อนบริการข, บริการ-C และบริการ-D

การแก้ไข: สร้างสคริปต์การรอสำหรับบริการ A. เรียกมันว่า "/etc/init/service-a-wait.conf"

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

สิ่งนี้หมายความว่าในภาษาอังกฤษธรรมดา: เมื่อสัญญาณบริการ b, c หรือ d ที่พวกเขาต้องการที่จะเริ่มพวกเขาต้องรอที่จะเริ่มจนกว่า service-a กำลังทำงานอยู่ งาน service-a-wait ถูกออกแบบมาให้ทำงานจนกว่า service-a ได้เริ่มต้นแล้ว เมื่อออกจากบริการแล้วรอตอนนี้บริการ b, c และ d มีอิสระที่จะดำเนินการต่อและทำงานได้

สิ่งนี้จะช่วยให้มั่นใจได้ว่าการให้บริการ a นั้นใช้งานได้และก่อนที่ความพยายามด้านการย้อนกลับใด ๆ ของมันจะเริ่มขึ้น

หมายเหตุ: บรรทัด "JOB $ JOB" มีความสำคัญในสถานการณ์ "เริ่มต้นใน ... หรือ .. หรือ .. " ไม่เช่นนั้นคุณจะบล็อกเฉพาะว่า B, C หรือ D ใดจะทำการดับก่อน

(การสร้างอินสแตนซ์สมควรได้รับการอธิบายที่ดีกว่าโดยสุจริตสำหรับตอนนี้เพียงแค่ทำมัน.)

— มาร์ครัสเซล
แหล่งที่มา

ฉันไม่ได้รับสิ่งนี้ ... สิ่งใดที่จะป้องกันไม่ให้สภาพการแข่งขันระหว่างบริการเริ่มต้นและบริการ B เริ่มต้นต่อไป ฉันไม่เห็นว่าคนธรรมดาจะรู้ได้อย่างไรว่าสคริปต์เสร็จสมบูรณ์ "start service-a" ... (ตำหนิสิ่งนี้ในเอกสารห่วย ๆ ของ Upstart อาจจะ…)

— Chris Pacejo

@ Mark Russell: ไม่ควรใช้normal exit 2บรรทัดนั้นnormal exit 0 2แทน บรรทัดแรกในส่วนค่อนข้างชัดเจนสามารถscript exit 0

— froage