Hey all, ran into the issue, that after updating from uwsgi 2.0.14-1 to uwsgi 2.0.14-5 (php plugin of the same version), all php based webapps make uwsgi segfault (tested with wordpress and stikked)! Something like the below will happen (including after reboot): Jan 17 16:24:20 frqrec systemd[1]: Starting uWSGI service unit... Jan 17 16:24:20 frqrec uwsgi[2370]: [uWSGI] getting INI configuration from /etc/uwsgi/wordpress.ini Jan 17 16:24:20 frqrec uwsgi[2370]: *** Starting uWSGI 2.0.14 (64bit) on [Tue Jan 17 16:24:20 2017] *** Jan 17 16:24:20 frqrec uwsgi[2370]: compiled with version: 6.3.1 20170109 on 10 January 2017 00:34:54 Jan 17 16:24:20 frqrec uwsgi[2370]: os: Linux-4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 Jan 17 16:24:20 frqrec uwsgi[2370]: nodename: frqrec Jan 17 16:24:20 frqrec uwsgi[2370]: machine: x86_64 Jan 17 16:24:20 frqrec uwsgi[2370]: clock source: unix Jan 17 16:24:20 frqrec uwsgi[2370]: pcre jit disabled Jan 17 16:24:20 frqrec uwsgi[2370]: detected number of CPU cores: 2 Jan 17 16:24:20 frqrec uwsgi[2370]: current working directory: / Jan 17 16:24:20 frqrec uwsgi[2370]: detected binary path: /usr/bin/uwsgi Jan 17 16:24:20 frqrec uwsgi[2370]: setgid() to 33 Jan 17 16:24:20 frqrec uwsgi[2370]: setuid() to 33 Jan 17 16:24:20 frqrec uwsgi[2370]: your processes number limit is 15780 Jan 17 16:24:20 frqrec uwsgi[2370]: your memory page size is 4096 bytes Jan 17 16:24:20 frqrec uwsgi[2370]: detected max file descriptor number: 1024 Jan 17 16:24:20 frqrec uwsgi[2370]: lock engine: pthread robust mutexes Jan 17 16:24:20 frqrec uwsgi[2370]: thunder lock: disabled (you can enable it with --thunder-lock) Jan 17 16:24:20 frqrec uwsgi[2370]: *** Cache "wordpress" initialized: 64MB (key: 2136 bytes, keys: 2136000 bytes, data: 65536000 bytes, bitmap: 0 bytes) preallocated *** Jan 17 16:24:20 frqrec uwsgi[2370]: - SystemD socket activation detected - Jan 17 16:24:20 frqrec uwsgi[2370]: uwsgi socket 1 attached to UNIX address /run/uwsgi/wordpress.sock fd 3 Jan 17 16:24:20 frqrec uwsgi[2370]: !!! uWSGI process 2370 got Segmentation Fault !!! Jan 17 16:24:20 frqrec uwsgi[2370]: *** backtrace of 2370 *** Jan 17 16:24:20 frqrec uwsgi[2370]: /usr/bin/uwsgi(uwsgi_backtrace+0x2c) [0x466eec] Jan 17 16:24:20 frqrec uwsgi[2370]: /usr/bin/uwsgi(uwsgi_segfault+0x21) [0x4672b1] Jan 17 16:24:20 frqrec uwsgi[2370]: /usr/lib/libc.so.6(+0x330b0) [0x7f9a019ea0b0] Jan 17 16:24:20 frqrec uwsgi[2370]: /usr/lib/uwsgi/php_plugin.so(+0x53ca) [0x7f9a001fa3ca] Jan 17 16:24:20 frqrec uwsgi[2370]: *** end of backtrace *** Jan 17 16:24:20 frqrec systemd[1]: uwsgi-private@wordpress.service: Main process exited, code=exited, status=1/FAILURE Jan 17 16:24:20 frqrec systemd[1]: Failed to start uWSGI service unit. Jan 17 16:24:20 frqrec systemd[1]: uwsgi-private@wordpress.service: Unit entered failed state. Jan 17 16:24:20 frqrec systemd[1]: uwsgi-private@wordpress.service: Failed with result 'exit-code'. Reverting back to uwsgi 2.0.14-1 fixes the problem (after restarting the socket, that activates the webapp). As a sidenote: I'm using the hardening and socket activation options as explained here, which shouldn't have much of an effect on the uwsgi itself though): https://wiki.archlinux.org/index.php/UWSGI#Socket_activation https://wiki.archlinux.org/index.php/UWSGI#Hardening_uWSGI Has anyone had the same issue? I can't seem to find out, what has changed between revision 1 and 5 or if it needs another rebuild. Best, David -- https://sleepmap.de
Attachment:
signature.asc
Description: PGP signature
