หัวหน้างานไม่โหลดไฟล์การกำหนดค่าใหม่

ฉันมีปัญหาในการปรับใช้แอพ Django โดยใช้ Gunicorn และ Supervisor ในขณะที่ฉันสามารถให้ Gunicorn ให้บริการแอปของฉัน (โดยการตั้งค่า PYTHONPATH ที่เหมาะสมและเรียกใช้คำสั่ง apropriate หนึ่งตัวจากการตั้งค่า supervisord) ฉันไม่สามารถทำให้หัวหน้างานเรียกใช้งานได้ มันจะไม่เห็นแอพของฉัน ฉันไม่ทราบวิธีการตรวจสอบให้แน่ใจว่าไฟล์ปรับแต่งนั้นใช้ได้

นี่คือสิ่งที่ supervisorctl พูดว่า:

# supervisorctl start myapp_live
myapp_live: ERROR (no such process)

ฉันใช้งานบน Ubuntu 10.04 ด้วยการกำหนดค่าต่อไปนี้:

ไฟล์ /home/myapp/live/deploy/supervisord_live.ini:

[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true

ใน /etc/supervisor/supervisord.conf ที่ส่วนท้ายของไฟล์มี:

[include]
files = /etc/supervisor/conf.d/*.conf

และนี่คือ symlink ในไฟล์ config ของฉัน:

# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root   48 Dec  4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini

ทุกอย่างดูดีสำหรับฉัน แต่ supervisorctl พูดmyapp_live: ERROR (no such process)ต่อไปเรื่อย ๆ มีทางออกสำหรับเรื่องนี้ไหม?

ฉันมีปัญหาเดียวกัน

sudo service supervisord reload

ทำกลอุบายแม้ว่าฉันจะไม่รู้ว่านั่นเป็นคำตอบสำหรับคำถามของคุณหรือไม่

คำตอบที่ถูกต้องคือหัวหน้างานต้องการให้คุณอ่านและอัปเดตใหม่เมื่อคุณวางไฟล์กำหนดค่าใหม่ การเริ่มต้นใหม่ไม่ใช่คำตอบเนื่องจากจะมีผลกับบริการอื่น ๆ ลอง:

supervisorctl reread
supervisorctl update

ตรวจสอบให้แน่ใจว่าไฟล์ผู้บังคับบัญชาของคุณลงท้ายด้วย. conf

เอาฉันไปสักพักเพื่อหาอันนั้น หวังว่ามันจะช่วยให้คนต่อไป

การโหลดกระบวนการหัวหน้างานใหม่อาจทำงานได้ แต่จะมีผลข้างเคียงที่ไม่ได้ตั้งใจหากคุณมีกระบวนการมากกว่าหนึ่งกระบวนการที่ถูกตรวจสอบโดยหัวหน้างาน

วิธีที่ถูกต้องที่จะทำคือการออกsupervisorctl rereadซึ่งทำให้มันสแกนไฟล์การกำหนดค่าสำหรับการเปลี่ยนแปลงใด ๆ :

root@debian:~# supervisorctl reread
gunicorn: changed

จากนั้นให้โหลดแอปนั้นอีกครั้ง:

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started

ฉันพบปัญหานี้โดยใช้แพ็คเกจผู้ดูแลระบบเวอร์ชัน 3.0a8-1.1 จาก Ubuntu Server 12.10 ฉันสิ้นสุดการแก้ไขปัญหาด้วยการอ่านความช่วยเหลือในตัว:

$ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

โดยเฉพาะอย่างยิ่งคุณต้องการใช้ไวยากรณ์:

sudo supervisorctl restart myapp_live:*

เนื่องจากเอกสารประกอบระบุไว้ที่http://supervisord.org/configuration.html#programx-section - "ส่วน [โปรแกรม: x] จริง ๆ แล้วหมายถึง" กลุ่มกระบวนการที่เป็นเนื้อเดียวกัน "ถึงผู้บังคับบัญชา (จาก 3.0)" ดังนั้นปัญหาอาจเกิดขึ้นครั้งแรกในรุ่น 3.0

PS: ฉันใหม่สำหรับผู้บังคับบัญชา; ฉันใช้https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisorเป็นตัวอย่างของการกำหนดค่าขั้นต่ำที่ควรมีลักษณะ

ฉันมีปัญหาที่คล้ายกัน ( myapp_live: ERROR (no such process)) และเป็นเพราะคำจำกัดความกระบวนการของฉันคือ

[program: myapp_live]

เมื่อมันควรจะเป็น

[program:myapp_live]

แม้ว่าสิ่งนี้จะไม่ตอบคำถามที่ถูกถาม แต่ฉันก็เป็นผู้นำในการค้นหาที่กำลังมองหาวิธีการแก้ไขปัญหาของฉันดังนั้นหวังว่าคนอื่นจะพบได้ที่นี่เช่นกัน

ฉันพบว่าวิธีนี้สะดวกที่สุด:

แก้ไข: ก่อนที่จะทำสิ่งนี้ให้ตรวจสอบเส้นทาง supervisorctl ของคุณที่ใช้which supervisorctlเพื่อให้แน่ใจว่าคุณกำลังเพิ่มเส้นทางที่ถูกต้องไปยัง sudoers

เพิ่มบรรทัดนี้ลงในไฟล์ sudoers โดยใช้visudo(โดย: myappuser- ผู้ใช้ที่ต้องการรีสตาร์ทแอปของคุณmyapp- ชื่อแอพ):

myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

แล้วก็:

sudo supervisorctl restart myapp

คุณไม่ได้ผูกติดกับสคริปต์เริ่มต้นของการแจกจ่ายและคุณให้สิทธิ์ผู้ใช้ในการรีสตาร์ทแอพ gunicorn ของคุณ นอกจากนี้คุณไม่จำเป็นต้องสนใจ pid คำสั่งจะไม่ถามรหัสผ่านดังนั้นจึงเหมาะสำหรับสคริปต์การปรับใช้ bash / fabric โดยอัตโนมัติ ในทางกลับกัน - คุณต้องระวังว่าถ้า supervisorctl มีความเสี่ยงต่อข้อผิดพลาดบางอย่างที่ทำให้เกิดการเรียกใช้รหัสผู้ใช้ที่เป็นอันตรายสามารถใช้สิทธิ์ sudo นี้เพื่อเรียกใช้รหัสเป็นราก (แต่เท่าที่ฉันรู้ว่าไม่มีข้อผิดพลาดดังกล่าว มันเป็นเรื่องใหญ่ที่จะพบช่องโหว่ดังกล่าว)

อ่านรหัสของ supervisorctl.py ที่นี่: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

คุณสามารถเห็นได้ว่าการปรับปรุง supervisorctl (ฟังก์ชั่น do_update) กำลังเรียก reloadConfig () เหมือนกันกับ supervisorctl reread (ฟังก์ชัน do_reread) ทำ

ดังนั้นฉันคิดว่าการเรียก reread นั้นไม่จำเป็นถ้าคุณเรียก update หลังจากนั้น

จากผลลัพธ์ของการตำหนิคอมไพล์มันเป็นแบบนี้มาตั้งแต่อย่างน้อยก็ตั้งแต่เดือนกรกฎาคม 2552

นี่คือรายการตรวจสอบ:

1. ไฟล์กำหนดค่าใหม่ควรตั้งชื่อตามรูปแบบรวมที่กำหนดค่าใน /etc/supervisord.conf:

   [include]
   files=supervisord.d/*.ini
   

   อย่างที่เราเห็นในกรณีของฉันจะมีการรวม spam.ini แต่ spam.conf จะไม่รวมอยู่ด้วย

2. หากคุณสร้างไฟล์ใหม่โดยการคัดลอกไฟล์เก่าอย่าลืมเปลี่ยน[program:]บรรทัด เพราะถ้าคุณโง่เหมือนมีสองไฟล์สำหรับโปรแกรมเดียวกันsupervisorctl rereadจะทำให้คุณมีข้อผิดพลาดที่สิ้นหวังเป็นการลงโทษ:

   No config updates to processes
   

3. หากตรวจพบไฟล์ของคุณsupervisorctl rereadควรพูดดังนี้:

   spam: available
   

4. จากนั้นทั้งสองควรจะเริ่มต้นมันและทำให้มันปรากฏในsupervisorctl update spamsupervisorctl status

ฉันพบว่าสคริปต์ init.d ไม่น่าเชื่อถือในรุ่นต่างๆของ Ubuntu / Debian วิธีที่จะทำคือ:

sudo supervisorctl reload

ระวังด้วย symlink และรวมไฟล์ไว้ใน Supervisor มันจะอนุญาตให้บุคคลที่มีสิทธิ์ w บน /home/myapp/live/deploy/supervisord_live.ini เปลี่ยนไฟล์ ini และเริ่มรหัสที่เป็นอันตรายใด ๆ ไฟล์ ini นี้ควรอยู่ในไดเรกทอรี conf ของหัวหน้างานหรือในส่วนย่อยใด ๆ

ฉันติดตั้ง supervisrod ด้วย yum install ซึ่งติดตั้ง supervisor ของเวอร์ชัน v2. * หัวหน้างานสนับสนุนการรวมภายนอกจากรุ่น 3 เท่านั้นต้องใช้ easy_install แทนเพื่อติดตั้ง supervisor v3