Package: uwsgi Version: 2.0.15-10.4 Severity: normal Control: affects -1 + searx
Hi, this might not even be a uwsgi bug, but filing it here anyways, because it leads to a segmentation fault in uwsgi (and no logs being written) which shouldn't happen. I found this bug when #900068 was filed against my package src:searx. Searx uses uwsgi to run and because of this issue, its autopkgtest doesn't complete anymore since the end of April: https://ci.debian.net/packages/s/searx/unstable/amd64/ I'm also able to reproduce this bug without searx, though. Steps to reproduce: $ sudo debootstrap sid debian-sid http://snapshot.debian.org/archive/debian/20180424T000000Z $ sudo chroot debian-sid passwd $ sudo systemd-nspawn -bD ~/debian-sid login with root and chosen password and then: # apt install uwsgi uwsgi-plugin-python3 nginx # cat > /var/www/hello.py << END def application(env, start_response): start_response('200 OK', [('Content-Type','text/html')]) return [b"Hello World"] END # cat > /etc/uwsgi/apps-enabled/hello.ini << END [uwsgi] uid = www-data gid = www-data chdir = /var/www module = python3 master = true END # systemctl restart uwsgi # systemctl status uwsgi Convince yourself that everything works just fine. Now upgrade the system to some new package versions of six days later: # echo 'deb http://snapshot.debian.org/archive/debian/20180430T000000Z sid main' > /etc/apt/sources.list # apt update -o Acquire::Check-Valid-Until=false # apt upgrade -o Acquire::Check-Valid-Until=false The following packages will be upgraded: file gcc-8-base ifupdown libargon2-0 libaudit-common libaudit1 libcap-ng0 libgcc1 liblognorm5 libmagic-mgc libmagic1 libncurses5 libncursesw5 libnorm1 libreadline7 libseccomp2 libstdc++6 libtinfo5 libzstd1 ncurses-base ncurses-bin perl-base vim-common vim-tiny xxd zlib1g After this upgrade, try restarting uwsgi and witness that it now fails to start: # systemctl restart uwsgi # systemctl status uwsgi ● uwsgi.service - LSB: Start/stop uWSGI server instance(s) Loaded: loaded (/etc/init.d/uwsgi; generated) Active: failed (Result: exit-code) since Sun 2018-05-27 06:59:20 CEST; 10min ago Docs: man:systemd-sysv-generator(8) Process: 38 ExecStart=/etc/init.d/uwsgi start (code=exited, status=1/FAILURE) May 27 06:59:17 hoothoot systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)... May 27 06:59:20 hoothoot uwsgi[38]: Starting app server(s): uwsgi -> ! failed! May 27 06:59:20 hoothoot systemd[1]: uwsgi.service: Control process exited, code=exited status=1 May 27 06:59:20 hoothoot systemd[1]: uwsgi.service: Failed with result 'exit-code'. May 27 06:59:20 hoothoot systemd[1]: Failed to start LSB: Start/stop uWSGI server instance(s). The root cause for this might be a segmentation fault. Try running the following which (I hope) correctly simulates what the init.d script does: # UWSGI_DEB_CONFNAME=hello UWSGI_DEB_CONFNAMESPACE=app uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/hello.ini [...] Sun May 27 07:10:47 2018 - spawned uWSGI worker 1 (pid: 282, cores: 1) Sun May 27 07:10:47 2018 - !!! uWSGI process 282 got Segmentation Fault !!! Sun May 27 07:10:47 2018 - spawned uWSGI worker 2 (pid: 283, cores: 1) Sun May 27 07:10:47 2018 - !!! uWSGI process 283 got Segmentation Fault !!! [...] Funnily, these segmentation faults also occur when only using default.ini: # UWSGI_DEB_CONFNAME=hello UWSGI_DEB_CONFNAMESPACE=app uwsgi --ini /usr/share/uwsgi/conf/default.ini I'm at a loss at how to debug this problem further. Thanks! cheers, josch
