https://bugs.archlinux.org/task/52406 the packager is a bit irresponsible On 17 January 2017 at 17:14, David Runge <dave@xxxxxxxxxxx> wrote: > 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 -- damjan
