Udev घटना पर लंबे समय तक प्रक्रिया कैसे चलाएं?

Question

जब मेरा USB मॉडेम जुड़ा होता है, तो मैं एक पीपीपी कनेक्शन चलाना चाहता हूं, इसलिए मैं इस udevनियम का उपयोग करता हूं :

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="16d8",\
    RUN+="/usr/local/bin/newPPP.sh $env{DEVNAME}"

(मेरा मॉडेम इस /devरूप में दिखाई देता है ttyACM0)

newPPP.sh:

#!/bin/bash
/usr/bin/pon prov $1 >/dev/null 2>&1 &

मुसीबत:

udevघटना की आग, और newPPP.sh चल रहा है, लेकिन newPPP.shप्रक्रिया ~ 4-5s के बाद मार दिया जाता है। pppकनेक्ट होने का समय नहीं है (इसका टाइमआउट डायल करने के लिए 10s है)।

मैं एक लंबी समय प्रक्रिया कैसे चला सकता हूं, जो नहीं मारा जाएगा?

मैंने प्रयोग करने की कोशिश की nohup, लेकिन यह भी काम नहीं किया।

सिस्टम: आर्क लिनक्स

अपडेट करें

मुझे यहां एक समाधान मिला , मैक्सस्क्लेज़िग के लिए धन्यवाद ।

मैं at nowअपने काम को udv प्रक्रिया से अलग करने के लिए उपयोग करता हूं।

लेकिन एक सवाल अनुत्तरित है: काम क्यों करते हैं nohupऔर क्या &नहीं?

Answer 1

यदि आप सिस्टमड सपोर्ट के साथ एक सभ्य वितरण चलाते हैं, तो डिवाइस यूनिट का उपयोग करना सबसे आसान और तकनीकी रूप से सबसे सुरक्षित तरीका है ।

इस तरह, सिस्टमड लंबे समय तक चलने वाली स्क्रिप्ट के पूर्ण नियंत्रण में होगा और डिवाइस के शटडाउन / निकाले जाने के बाद भी प्रक्रिया को ठीक से समाप्त करने में सक्षम होगा - इस प्रक्रिया का पता लगाने का मतलब है कि आप प्रक्रिया राज्य के पूर्ण नियंत्रण में हैं। और इसका इतिहास।

इसके अलावा, आप डिवाइस की स्थिति का निरीक्षण करने में सक्षम होंगे और यह रनिंग द्वारा संलग्न सेवा है systemctl status my-ppp-thing.device।

यह भी देखें इस ब्लॉग पोस्ट कुछ और उदाहरण और जानकारी के लिए।

Answer 2

आजकल udv cgroups का उपयोग spawned कार्यों की तलाश-एन-नष्ट करने के लिए करता है। एक समाधान "अब" या "बैच" का उपयोग करना है। एक और उपाय है डबल कांटा और "क्रॉचोलेट" प्रक्रिया को दूसरे cgroup में करना। यह एक उदाहरण अजगर कोड है (इसी तरह का कोड किसी भी भाषा में लिखा जा सकता है):

os.closerange(0, 65535)  # just in case
pid = os.fork()
if not pid:
  pid = os.fork()  # fork again so the child would adopted by init
  if not pid:
    # relocate this process to another cgroup
    with open("/sys/fs/cgroup/cpu/tasks", "a+") as fd:
      fd.write(str(os.getpid()))
    sleep(3)  # defer execution by XX seconds
    # YOUR CODE GOES HERE
sleep(0.1)  # get forked process chance to change cgroup

डिबग आउटपुट को भेजा जा सकता है, जैसे, syslog।

Comments

Udv स्पैन्ड प्रक्रियाओं को नष्ट करने के लिए इतनी लंबाई में क्यों जाएगा?

— user30747

मैं यह अनुमान लगा रहा हूं क्योंकि udev द्वारा शुरू किए गए कार्यक्रम डेमॉन को ब्लॉक करते हैं (जैसे बाहरी डिस्प्ले में प्लगिंग से जुड़ा एक udev नियम, लंबे समय तक चलने वाला प्रोग्राम नए डिस्प्ले को वास्तव में इस्तेमाल होने से रोक देगा)। मुझे यकीन है कि इसके पीछे अपने स्वयं के तकनीकी तर्क हैं, लेकिन इसका मतलब है कि स्पैन्ड प्रक्रियाएं सिस्टम के प्रमुख हिस्सों को पकड़ सकती हैं और उन्हें मारने की आवश्यकता होती है।

— टोकब

Answer 3

शेल में पृष्ठभूमि में कमांड चलाने की क्षमता है:

(

lots of code

) &

एम्परसेंड के साथ ब्रेसिज़ द्वारा समूहीकृत कमांड को एक उपधारा में अतुल्यकालिक रूप से निष्पादित किया जाएगा। जब USB मॉडेम डाला जाता है और स्विच किया जाता है तो मैं इसे ऑटोकनेक्ट करने के लिए उपयोग करता हूं। यह लगभग 20 सेकंड लेता है और udev के तहत ठीक काम करता है।

Comments

आप ऐसी स्थिति में stderr, stdout और stderr को पुनर्निर्देशित कर सकते हैं।

— mdpc

@mdpc हम्म ... क्यों? मैंने इस परिदृश्य में usb_modeswitch बंद धाराएं देखीं: निष्पादन 1 <& - 2 <& - 5 <& - 7 <& - 7

— user42295

Answer 4

मुझे यह सेटिस्दे के साथ काम करने के लिए मिला। Udv नियम का मेरा भाग भाग:

RUN+="/bin/bash script.sh"

फिर स्क्रिप्ट में:

#!/bin/bash
if [ "$1" != "fo_real" ]; then
  /usr/bin/setsid $(/usr/bin/dirname $0)/$(/usr/bin/basename $0) fo_real &
  exit
fi

Rest of script is here....

स्क्रिप्ट की पहली कॉल निकास स्थिति 0 के साथ लौटती है, लेकिन स्क्रिप्ट के लिए दूसरी कॉल PPID = 1 के साथ चलती रहती है।

Answer 5

शायद इसलिए कि इसकी मूल प्रक्रिया समाप्त हो गई है और समाप्ति संकेत अपने बच्चों के लिए प्रचारित करता है, जो इसे अवरुद्ध नहीं करते हैं (और यदि SIGKILLवे भी नहीं कर सकते हैं तो)।