የመጠባበቂያ ሉፃችን ራሱን ለመጠበቅ 35 ሰዓቶች ቆይቷል፡ በSSH በኩል pgrep -f እና pkill -f

ኦፕስ2026-11-02

በ31 ጥር ትንሽ ሉፕ በSSH በኩል ጀመርን፡ በሌላ ማሽን ላይ ያለ የትርጉም ስራ ሲጠናቀቅ ድረስ መጠበቅ፣ ከዚያም ተከታይ ስራን ማሽከርከር። የትርጉም ስራው በዚያው ሌሊት ተጠናቀቀ። ከሁለት ቀናት በኋላ ስንመለከት፣ ሉፑ ለ35 ሰዓቶች እየጠበቀ ነበር፣ ተከታዩ ስራ ግን ፈጽሞ አልተሰራም።

ሉፑ ምን ነበር

ssh build-host 'while pgrep -f "i18n_job.py example.com" >/dev/null; do sleep 30; done; ./follow-up.sh'

pgrep -f ንድፉን ከእያንዳንዱ ሂደት ሙሉ የትዕዛዝ መስመር ጋር ያነጻጽራል። SSH የተጠቀሰውን ትዕዛዝ እንደ bash -c 'while pgrep -f "i18n_job.py example.com" …' ያሽከርክራል፣ ያ ትዕዛዝ መስመርም ንድፉን ይዟል። pgrep የራሱን ሂደት ከውጤቶች ያስወግዳል፣ ነገር ግን የጀመረውን ሼል አያስወግድም። ስለዚህ ሉፑ ሕያው እስከሆነ ድረስ፣ ግጭት ያገኛል፡ ራሱን።

እንደ ወንድሙ፡ pkill -f የሚሰራበትን ሼል ይገድላል

ተመሳሳይ ነገር ከpkill -f ጋር ይከሰታል፣ ውጤቱም የተሻለ አይደለም፡

ssh build-host 'pkill -f "worker.py --queue a"; nohup python3 worker.py --queue a &'

የሼሉ የራሱ የትዕዛዝ መስመር ንድፉን ስለያዘ፣ pkill ሼሉን ይገድላል። ሠራተኛው ቆሟል እና እንደገና አልተጀመረም፣ SSHም ሳይሆን በስህተት መልእክት ያለው ኮድ 255 ይወጣል። የጥቅስ ችግር ይመስላል፣ በመጀመሪያ ጊዜ እኛም እንደዚያ አድርገን ነበር የወሰድነው።

ከመስከረም እስከ ጥር መጨረሻ ቢያንስ አስር ጊዜ ወደ አንዱ ወይም ወደ ሌላው ወድቀናል፡ ፈጽሞ ያልተከሰቱ እንደገና ማስጀመሪያዎች፣ ለሦስት ሰዓት እና ግማሽ ሰዓት ማረጋገጫን የያዘ ሉፕ፣ ሌላውም የትርጉም ወረፋን ለ50 ደቂቃ የያዘ፣ እና ይህም።

አሁን የምናደርገው

• በንድፉ ውስጥ ቅንፍ፡ pgrep -f "[i]18n_job.py example.com"። እንደ መደበኛ አገላለጽ፣ [i] ፊደል iን ይዛመዳል፣ ስለዚህ ስራው አሁንም ይዛመዳል፤ የሼሉ የትዕዛዝ መስመር ግን [i] የሚሉ ቁምፊዎችን ይዟል፣ አገላለጹ ግን እነዚህን አይዛመድም። ግልጽ ንድፉ በዚያ መስመር ላይ በሌላ ቦታ ሳይታይ ከሆነ ብቻ ይረዳል፡ በተመሳሳይ መስመር በኋላ የሚመጣ የእንደገና ማስጀመሪያ ትዕዛዝ እንደገና ይዛመዳል።
• ማግኘት፣ ማቆም እና ማስጀመርን በተለያዩ የSSH ጥሪዎች ውስጥ። አንዱ ጥሪ ሂደቶችን በpgrep -af ይዘረዝራል፣ ቀጣዩ የታተሙትን PIDs ይገድላል፣ ሦስተኛው አዲሱን ሂደት ያስጀምራል።
• በንድፍ ሳይሆን በPID ላይ ይጠብቁ፡ tail --pid=1234 -f /dev/null፣ ወይም while kill -0 1234; do sleep 30; done።
• ከዚያም የተሻለው፣ systemd ስራውን እንዲቆጣጠር ያድርጉ። እንደ አንድ ክፍል (unit) ያስኬዱት እና systemctl is-active ይጠይቁ፣ ወይም በsystemd-run --wait ያስጀምሩት። የሚስሉት ምንም ምሳሌ የለም።
• እያንዳንዱ መጠበቅ የመጨረሻ ጊዜ (deadline) ይኑረው (timeout 3h) እና መቼ እንደሚሰናበት ይንገሩ። የመጨረሻ ጊዜ የሌለው ዑደት ዝም ብሎ ይገታል።

Factory Floor ማሽኖቻችንን የሚያስኬደው የሶፍትዌር ጥቅል፣ በsystemd ክፍሎች (units) ይሰራል፡ ምንጊዜም ሂደትን በትዕዛዝ መስመሩ (command line) አይፈልግም። የጎዱንን ዑደቶች እኛ በእጅ የጻፍናቸው ነበሩ።