উদেব ইভেন্টে কীভাবে দীর্ঘ সময় প্রক্রিয়া চালানো যায়?

Question

আমার ইউএসবি মডেম সংযুক্ত থাকাকালীন আমি পিপিপি সংযোগ চালাতে চাই , তাই আমি এই 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, তবে এটিও কার্যকর হয়নি।

সিস্টেম: আর্চ লিনাক্স

হালনাগাদ

আমি একটি সমাধান পাওয়া এখানে , ধন্যবাদ maxschlepzig ।

আমি at nowআমার কাজটি ইউদেব প্রক্রিয়া থেকে আলাদা করে চালানোর জন্য ব্যবহার করি।

তবে একটি প্রশ্ন উত্তরহীন রয়ে গেছে: কেন nohupএবং &কাজ করে না?

Answer 1

আপনি যদি সিস্টেমড সমর্থন সহ একটি শালীন বিতরণ চালনা করেন তবে কোনও ডিভাইস ইউনিট ব্যবহার করা সবচেয়ে সহজ এবং প্রযুক্তিগতভাবে নিরাপদতম উপায় ।

এই পদ্ধতিতে সিস্টেমেড দীর্ঘস্থায়ী স্ক্রিপ্টের সম্পূর্ণ নিয়ন্ত্রণে থাকবে এবং ডিভাইসটি শাটডাউন / মুছে ফেলার পরে প্রক্রিয়াটি যথাযথভাবে বন্ধ করতে সক্ষম হবে - প্রক্রিয়াটিকে বিচ্ছিন্ন করার অর্থ আপনি প্রক্রিয়া রাষ্ট্রের সম্পূর্ণ নিয়ন্ত্রণে চলে যাচ্ছেন এবং এর ইতিহাস।

তদতিরিক্ত, আপনি ডিভাইসের স্থিতি এবং এটি চালিত দ্বারা সংযুক্ত পরিষেবাটি পরীক্ষা করতে সক্ষম হবেন systemctl status my-ppp-thing.device।

আরও কিছু উদাহরণ এবং বিশদ জন্য এই ব্লগ পোস্ট দেখুন।

Answer 2

আজকাল উদেব স্যান-এন-ডিগ্রিযুক্ত কাজগুলি সন্ধান করতে সিগ্রুপ ব্যবহার করে। একটি সমাধান হ'ল "এখন" বা "ব্যাচ" ব্যবহার করা। আরেকটি সমাধান হ'ল ডাবল কাঁটাচামচ করা এবং অন্য সিগ্রুপে "স্থানান্তর" প্রক্রিয়া। এটি পাইথন কোডের উদাহরণ (একই ভাষায় যে কোনও ভাষায় লেখা যেতে পারে):

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

কেন ইউদেব প্রসেস প্রসেসগুলি ধ্বংস করতে এত দূরত্বে যাবে?

— ব্যবহারকারী 30747

আমি এটি অনুমান করছি কারণ উদেব দ্বারা শুরু হওয়া প্রোগ্রামগুলি ডেমোনকে ব্লক করে (যেমন কোনও বাহ্যিক ডিসপ্লেতে প্লাগিংয়ের সাথে সংযুক্ত কোনও উদেব নিয়ম সহ, একটি দীর্ঘ-চলমান প্রোগ্রামটি নতুন ডিসপ্লেটিকে বাস্তবে ব্যবহার করা থেকে বিরত করবে)। আমি নিশ্চিত যে এর পেছনে এর নিজস্ব প্রযুক্তিগত যুক্তি রয়েছে, তবে এর অর্থ হ'ল প্রসেস প্রক্রিয়াগুলি সিস্টেমের বড় অংশগুলিকে ধারণ করতে পারে এবং হত্যা করা দরকার।

— টোবাক

Answer 3

শেল পটভূমিতে কমান্ড চালানোর ক্ষমতা রাখে:

(

lots of code

) &

ধনুর্বন্ধনী দ্বারা অ্যাম্পারস্যান্ডের পরে গোষ্ঠীভুক্ত কমান্ডগুলি একটি সাবচেলে সংবিধানে কার্যকর করা হবে। আমি যখন ইউএসবি মডেম sertedোকানো এবং স্যুইচ করা হয় তখন আমি স্বতঃসংযোগ করতে এটি ব্যবহার করি। এটি প্রায় 20 সেকেন্ড সময় নেয় এবং udev এর অধীনে সূক্ষ্মভাবে কাজ করে।

Comments

আপনি স্টেরার, স্টডআউট এবং স্ট্যাডারকে এমন পরিস্থিতিতে পুনঃনির্দেশ করতে চাইতে পারেন।

— এমডিপিসি

@ এমডিপিসি হুম ... কেন? আমি ইউএসবি_মোডসইচকে এই দৃশ্যে স্রোতগুলি বন্ধ করে দেখলাম: এক্সিকিউটিভ 1 <& - 2 <& - 5 <& - 7 <& -

— ব্যবহারকারী 42295

Answer 4

সেটসিড নিয়ে কাজ করতে পেরেছি। উদেব নিয়মের আমার আরএন অংশ:

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 দিয়ে ফিরে আসে, তবে স্ক্রিপ্টের দ্বিতীয় কলটি পিপিআইডি = 1 দিয়ে চলতে থাকে।

Answer 5

সম্ভবত কারণ এটির মূল প্রক্রিয়াটি শেষ হয়ে গেছে এবং সমাপ্তি সংকেতটি তার বাচ্চাদের কাছে প্রচার করে যা এটিকে অবরুদ্ধ করে না (এবং SIGKILLএমনকি তারা না পারার ক্ষেত্রেও )।