init.d 스크립트를 통해 UWSGI를 시작하면 종료 코드 1로 종료되고 "실패"가 표시되지만 프로세스는 정상적으로 실행됩니다.

init.d 스크립트를 통해 UWSGI를 시작하면 종료 코드 1로 종료되고 "실패"가 표시되지만 프로세스는 정상적으로 실행됩니다.

이것이 중복으로 표시되기 전에 나는 읽었습니다.이 문제; 그러나 추가해도 logfile2아무 것도 변경되지 않습니다.


저는 현재 UWSGI를 사용하여 Python 스택을 실행하는 docker 컨테이너를 만들고 있습니다. 이를 위해 uwsgi의 기본 Debian 설치를 스크립트로 사용 init.d하고 pip.

그런데 서비스를 시작할 때마다 스크립트를 시작할 수 없다는 오류가 출력되는데, 서버()에 요청을 하거나 다음을 사용하여 프로세스가 localhost:5000실행 중인지 확인하려고 하면ps aux | grep -i uwsgi

내가 의미하는 바의 예:

root@f16b3268a956:~# /etc/init.d/uwsgi start
[FAIL] Starting app server(s): uwsgi -> ! failed!

그러나 실행중인 프로세스를 보면

root@f16b3268a956:~# ps aux | grep -i uwsgi
user       984  0.1  2.8 235284 57876 ?        S    14:15   0:00 /usr/local/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/portal.ini --daemonize /var/log/uwsgi/app/portal.log
user      1009  0.0  2.7 253204 57040 ?        S    14:15   0:00 /usr/local/bin/uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/portal.ini --daemonize /var/log/uwsgi/app/portal.log
root      1146  0.0  0.0  12860   976 pts/0    S+   14:24   0:00 grep -i uwsgi

내 uwsgi 구성 내용:

[uwsgi]
http-socket = localhost:5000
http-websockets = true
chmod-socket=775
chdir = /home/user/
master = true
binary-path = /usr/local/bin/uwsgi
virtualenv = /home/user/portal
module = portal.server:app
uid = user
gid = user
processes = 1
gevent = 1000
logfile2 = /tmp/test.pid
logto = /var/log/uwsgi/app/portal.log

로그 파일을 봐도 이상한 것이 표시되지 않습니다.

root@f16b3268a956:~# cat /var/log/uwsgi/app/portal.log
Thu Oct 25 14:29:48 2018 - *** Starting uWSGI 2.0.17.1 (64bit) on [Thu Oct 25 14:29:48 2018] ***
Thu Oct 25 14:29:48 2018 - compiled with version: 6.3.0 20170516 on 25 October 2018 13:26:09
Thu Oct 25 14:29:48 2018 - os: Linux-4.9.87-linuxkit-aufs #1 SMP Wed Mar 14 15:12:16 UTC 2018
Thu Oct 25 14:29:48 2018 - nodename: f16b3268a956
Thu Oct 25 14:29:48 2018 - machine: x86_64
Thu Oct 25 14:29:48 2018 - clock source: unix
Thu Oct 25 14:29:48 2018 - pcre jit disabled
Thu Oct 25 14:29:48 2018 - detected number of CPU cores: 4
Thu Oct 25 14:29:48 2018 - current working directory: /
Thu Oct 25 14:29:48 2018 - writing pidfile to /run/uwsgi/app/portal/pid
Thu Oct 25 14:29:48 2018 - detected binary path: /usr/local/bin/uwsgi
Thu Oct 25 14:29:48 2018 - setgid() to 1000
Thu Oct 25 14:29:48 2018 - setuid() to 1000
Thu Oct 25 14:29:48 2018 - chdir() to /home/user/
Thu Oct 25 14:29:48 2018 - writing pidfile to /tmp/test.pid
Thu Oct 25 14:29:48 2018 - your memory page size is 4096 bytes
Thu Oct 25 14:29:48 2018 - detected max file descriptor number: 1048576
Thu Oct 25 14:29:48 2018 - - async cores set to 1000 - fd table size: 1048576
Thu Oct 25 14:29:48 2018 - lock engine: pthread robust mutexes
Thu Oct 25 14:29:48 2018 - thunder lock: disabled (you can enable it with --thunder-lock)
Thu Oct 25 14:29:48 2018 - uwsgi socket 0 bound to UNIX address /run/uwsgi/app/portal/socket fd 3
Thu Oct 25 14:29:48 2018 - uwsgi socket 1 bound to TCP address localhost:5000 fd 5
Thu Oct 25 14:29:48 2018 - Python version: 3.6.6 (default, Sep  5 2018, 03:40:52)  [GCC 6.3.0 20170516]
Thu Oct 25 14:29:48 2018 - Set PythonHome to /home/user/portal
Thu Oct 25 14:29:48 2018 - Python main interpreter initialized at 0x563332cd13a0
Thu Oct 25 14:29:48 2018 - python threads support enabled
Thu Oct 25 14:29:48 2018 - your server socket listen backlog is limited to 100 connections
Thu Oct 25 14:29:48 2018 - your mercy for graceful operations on workers is 60 seconds
Thu Oct 25 14:29:48 2018 - mapped 21036928 bytes (20543 KB) for 1000 cores
Thu Oct 25 14:29:48 2018 - *** Operational MODE: async ***
Thu Oct 25 14:29:49 2018 - WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x563332cd13a0 pid: 1814 (default app)
Thu Oct 25 14:29:49 2018 - *** uWSGI is running in multiple interpreter mode ***
Thu Oct 25 14:29:49 2018 - spawned uWSGI master process (pid: 1814)
Thu Oct 25 14:29:49 2018 - spawned uWSGI worker 1 (pid: 1839, cores: 1000)
Thu Oct 25 14:29:49 2018 - *** running gevent loop engine [addr:0x5633314d0fd0] ***

이 문제를 해결하는 방법을 아는 사람이 있나요?

답변1

결국 내 이미지를 기반으로 이 문제를 해결했습니다.다음 도커 이미지init.d 프로세스 대신 Supervisord를 사용합니다(systemctl 없음).

답변2

--cap-add SYS_PTRACE에 전달해야 합니다 docker run. 그렇지 않으면 start-stop-daemon데몬이 실행 중인지 감지되지 않고 init 스크립트가 실패합니다.

관련 정보