मैं कैसे सुनिश्चित करूं कि एक प्रक्रिया चल रही प्रक्रिया वह प्रक्रिया है जिसे मैं उम्मीद कर रहा हूं?

Question

प्रसंग:

मैं एक linux [1] प्रणाली है कि तीसरे पक्ष के डेमॉन के जो के साथ बातचीत शैल तक ही सीमित हैं की एक श्रृंखला प्रबंधन करता है [2] init स्क्रिप्ट, यानी केवल {शुरू | पुनः आरंभ | रोक | status} उपलब्ध हैं।

समस्या:

प्रक्रियाओं एक पहले से चल रहा है की प्रक्रिया के पीआईडी ​​मान सकते हैं, प्रक्रियाओं की स्थिति चल रहे प्रक्रियाओं के साथ यह पीआईडी ​​है की उपस्थिति का निरीक्षण द्वारा जाँच कर रहे हैं।

उदाहरण:

प्रक्रिया एक रन के पीआईडी ​​123 के साथ, बाद में मर जाता है, पीआईडी ​​123 और स्थिति कमांड के साथ प्रक्रिया बी initialises एक unauthentic (गलत) के साथ प्रतिक्रिया "ठीक है"। दूसरे शब्दों में, हम केवल पीआईडी ​​से प्रक्रिया की उपस्थिति की जांच करने के लिए जांच करते हैं कि प्रक्रिया चल रही है, हम मानते हैं कि इस पीआईडी ​​के साथ एक प्रक्रिया मौजूद है, यह प्रक्रिया में प्रक्रिया है।

प्रस्तावित समाधान:

1. प्रक्रिया पूछताछ, पीआईडी ​​का उपयोग कर, आदेश/डेमॉन के रूप में है कि पीआईडी ​​अपेक्षा के अनुरूप है चल रहा है सुनिश्चित करने के लिए। इस समाधान के साथ समस्या यह है कि कमांड और पीआईडी ​​दोनों को मिलान करने की आवश्यकता है; जानकारी के कई बिट्स को इस प्रकार बनाए रखने और सिंक में रखने की आवश्यकता है, और त्रुटि/किनारे की स्थितियों में अतिरिक्त जटिलता जोड़ें।
2. प्रक्रिया के प्रारंभ समय के साथ पीआईडी ​​फ़ाइल के निर्माण समय को सहसंबंधित करें, यदि प्रक्रिया पीआईडी ​​फ़ाइल निर्माण समय के एक निश्चित डेल्टा के भीतर है, तो हम निश्चित रूप से निश्चित हो सकते हैं कि कमांड/डिमन चलने की उम्मीद है।

क्या पीआईडी ​​के साथ चल रही प्रक्रिया की उपस्थिति से परे, प्रक्रिया/पीआईडी ​​फ़ाइल की प्रामाणिकता को प्रमाणित करने का कोई मानक तरीका है? अर्थात। मैं (सिस्टम के रूप में) जानना चाहता हूं कि आप (प्रक्रिया) चल रहे हैं और यदि आप हैं जो मुझे लगता है कि आप हैं (ए और नहीं बी)।

मान लीजिए कि हमने ऊपर प्रस्तावित दूसरे समाधान को लागू करने के लिए चुना है, पीआईडी ​​निर्माण समय और प्रक्रिया प्रारंभ समय के बीच आत्मविश्वास अंतराल/डेल्टा क्या उचित है? यहां, उचित प्रकार टाइप 1/टाइप 2 त्रुटियों के बीच स्वीकार्य समझौता है।

[1] CentOS/RHEL [2] बैश

Answer 1

फ़ाइल की सामग्री:

/proc/{पीआईडी}/cmdline

कमांड लाइन प्रयोग किया जाता है प्रक्रिया शुरू करने के लिए। क्या आपको इसकी आवश्यकता है?

Answer 2

मेरा समाधान सापेक्ष प्रारंभ समय के साथ आदेश (/proc/PID/cmdline के माध्यम से) को कैप्चर करना था। absolute start time (ps -p PID -o lstart= के माध्यम से) काम करने के लिए प्रतीत होता है, लेकिन आपको confusing results if your system clock changes (उदा। एनटीपी अपडेट, या डेलाइट सेविंग्स) मिलेगा।

# Prints enough detail to confirm a PID still refers to the same process. 
# In other words, even if a PID is recycled by a call to the same process the 
# output of this command should still be different. This is not guaranteed 
# across reboots. 
proc_detail() { 
    local pid=${1:?Must specify PID} 
    # the process' commandline, if it's running 
    # ensures a non-existant PID will never have the same output as a running 
    # process, and helps debugging 
    cat "/proc/$pid/cmdline" 2> /dev/null && echo 
    # this is the number of seconds after boot that the process started 
    # https://unix.stackexchange.com/a/274722/19157 
    # in theory this could collide if the same process were restarted in the same 
    # second and assigned the same PID, but PIDs are assigned in order so this 
    # seems acceptably unlikely for now. 
    echo "$(($(cut -d. -f1 < /proc/uptime) - \ 
      $(ps -p "$pid" -o etimes= 2> /dev/null || echo "0")))" 
} 

मैं भी इतना है कि यह शटडाउन होने पर मेरे लिए स्वचालित रूप से मंजूरी दे दी है /dev/shm में इस उत्पादन को स्टोर करने का फैसला किया:

यहाँ मेरी कार्यान्वयन है। अन्य व्यवहार्य विकल्प हैं (जैसे @reboot क्रोनबॉज) लेकिन मेरे उपयोग के मामले में tmpfs पर लिखना आसान और साफ था।