Ang aming wait loop ay naghintay ng 35 oras para sa sarili nito: pgrep -f at pkill -f sa pamamagitan ng SSH

Ops2026-11-02

Noong 31 Oktubre, nagsimula kami ng maliit na loop sa pamamagitan ng SSH: hintayin hanggang matapos ang isang translation job sa ibang machine, pagkatapos ay patakbuhin ang isang follow-up job. Natapos ang translation job sa gabi na iyon. Nang tingnan namin ulit dalawang araw ang nakalipas, ang loop ay naghihintay na ng 35 oras, at hindi kailanman tumakbo ang follow-up.

Ano ang loop

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

Ang pgrep -f ay tumutugma sa isang pattern sa buong command line ng bawat process. Pinapatakbo ng SSH ang naka-quote na command bilang bash -c 'while pgrep -f "i18n_job.py example.com" …', at ang command line na iyon ay naglalaman ng pattern. Inilalayo ng pgrep ang sarili nitong process mula sa mga resulta, ngunit hindi ang shell na nagsimula nito. Kaya hangga't buhay ang loop, nakakahanap ito ng tugma: ang sarili nito.

Ang kasing-kulay nito: pinapatay ng pkill -f ang shell kung saan ito tumatakbo

Ganito rin ang nangyayari sa pkill -f, na may mas masamang resulta:

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

Ang command line ng shell mismo ay naglalaman ng pattern, kaya pinapatay ng pkill ang shell. Titigil ang worker at hindi na ito muling sisimulan, at lalabas ang SSH na may code 255 nang walang error message. Mukhang problema sa pag-quote ito, na ang akala namin noong unang beses.

Sa pagitan ng Setyembre at katapusan ng Oktubre, nahulog kami sa isa o sa isa pang sitwasyon nang hindi bababa sa isang dosena: mga restart na hindi nangyari, isang loop na nag-hold ng check sa loob ng tatlong oras at kalahating oras, isa pang nag-hold ng translation queue sa loob ng 50 minuto, at ang ito.

Ang ginagawa namin ngayon

• Isang bracket sa pattern: pgrep -f "[i]18n_job.py example.com". Bilang isang regular expression, tumutugma ang [i] sa letra i, kaya tumutugma pa rin ang job; ang command line ng shell ay naglalaman ng mga character na [i], na hindi tumutugma sa expression. Makakatulong lamang ito kung ang simpleng pattern ay wala sa ibang bahagi ng linya: ang isang restart command sa ibaba ng parehong linya ay muling tumutugma.
• Hanapin, ihinto at simulan sa hiwalay na SSH calls. Isang call ang naglilista ng mga processes gamit ang pgrep -af, ang susunod ang pumapatay sa mga PID na ini-print nito, ang pangatlo ang nagsisimula ng bagong process.
• Maghintay sa PID, hindi sa pattern: tail --pid=1234 -f /dev/null, o while kill -0 1234; do sleep 30; done.
• Mas mabuti pa, hayaang pamahalaan ng systemd ang trabaho. I-run ito bilang unit at itanong ang systemctl is-active, o simulan ito gamit ang systemd-run --wait. Walang pattern na maaaring maliin.
• Bawat paghihintay ay may deadline (timeout 3h) at sinasabi nito kung kailan ito susuko. Ang loop na walang deadline ay bumabagsak nang tahimik.

Factory Floor, ang kit na pinapatakbo ng aming mga makina, ay gumagana sa pamamagitan ng systemd units: hindi nito hinahanap ang isang process base sa command line nito. Ang mga loop na nagdulot ng problema sa amin ay ang mga itinype namin nang kamay.