Bug#900273: closed by Thomas Goirand (Re: Bug#900273: uwsgi: Segmentation fault with autoload = true)
"Debian Bug Tracking System" writes: > This is an automatic notification regarding your Bug report > which was filed against the uwsgi package: > > #900273: uwsgi: Segmentation fault with autoload = true > > It has been closed by Thomas Goirand . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Thomas Goirand > by > replying to this email. > > > -- > 900273: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900273 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > From: Thomas Goirand > Subject: Re: Bug#900273: uwsgi: Segmentation fault with autoload = true > To: 900273-d...@bugs.debian.org > Date: Mon, 28 May 2018 18:17:39 +0200 > > On 05/28/2018 11:47 AM, Andreas Admin wrote: >> After much cursing, I discovered that the script >> /usr/share/uwsgi/init/specific_daemon, >> specifically the start-stop-daemon line, redirects stdout and stderr to >> /dev/null, which prevented me from seeing the error messages. That is >> issue number one--I don't think masking errors is good practice. > > You are probably right with that last sentence, though it must have been > made this way to prevent bad output in normal operation, when there's no > issue, and without the intend to just mask errors (but with the intent > to provide nice output when things work). > > I guess that if something goes wrong, then you can simply comment out > the redirection, and try again, no? The reason I reported this bug is to (a) create a public record of the issue I ran into and (b) to potentially make life easier for other folks who could save themselves a few hours by not falling into this needless trap. In my book, the trade-off between "no error message for a complete failure of the software" and "some measure of ugly log spam" is entirely clear. I'm sorry to hear you feel otherwise. >> As a lucky guess, I disabled autoload=true in the default config, and >> that cured the segfaults--even if I don't understand why. > > The autoload=true is for uwsgi to try to double-guess the type of plugin > to load depending on the type of application. Obviously, uwsgi failed to > do so in your case, and crashed. So something must be wrong in that > autodetection thing, probably also because of some configuration hints > not good enough (I'm not sure, just double-guessing here, since you > haven't provided the .ini file used to start your application). > > I don't see this as a very bad failure, just a feature which is nice to > have that fails, not compromising the normal mode of operation. You may not have heard me right. I agree that 'autoload=true' appears to be a terrible idea, especially given the failure mode I observed. The problem is that your package defaults it to true, i.e. defaults the package to unusable on machines that run into the same issue as mine. I implore you to change the default to 'autoload=false' in /usr/share/uwsgi/conf/default.ini. Also, thank you for the work you put into maintaining packages for Debian. Andreas
Bug#900273: uwsgi: Segmentation fault with autoload = true
On 05/28/2018 11:47 AM, Andreas Admin wrote: > As a lucky guess, I disabled autoload=true in the default config, and > that cured the segfaults--even if I don't understand why. That's the > second issue I'm reporting. BTW, your issue is similar to: https://bugs.debian.org/900174 Can you also try with libcap-ng0 0.7.7-3.1+b1 please? Cheers, Thomas Goirand (zigo)
Bug#900273: uwsgi: Segmentation fault with autoload = true
Package: uwsgi Version: 2.0.15-11 Severity: important Dear Maintainer, I've found multiple issues with the package. First, recently uwsgi simply seemed to stop working. (reported failure without an error message after being started through systemd) This coincided with the upgrade to 2.0.15-11, but I don't think that that was the root cause. After much cursing, I discovered that the script /usr/share/uwsgi/init/specific_daemon, specifically the start-stop-daemon line, redirects stdout and stderr to /dev/null, which prevented me from seeing the error messages. That is issue number one--I don't think masking errors is good practice. This finally clued me in that I was dealing with segfaults: May 27 13:12:43 badger uwsgi[608]: [uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/expensely.ini May 27 13:12:44 badger uwsgi[608]: Sun May 27 13:12:44 2018 - !!! uWSGI process 1050 got Segmentation Fault !!! May 27 13:12:44 badger exim4[631]: Starting MTA: exim4. May 27 13:12:44 badger systemd[1]: Started LSB: exim Mail Transport Agent. May 27 13:12:46 badger systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch. May 27 13:12:47 badger uwsgi[608]: app/expensely![uWSGI] getting INI configuration from /usr/share/uwsgi/conf/default.ini May 27 13:12:47 badger uwsgi[608]: [uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/gitweb.ini May 27 13:12:47 badger uwsgi[608]: Sun May 27 13:12:47 2018 - !!! uWSGI process 1297 got Segmentation Fault !!! May 27 13:12:50 badger uwsgi[608]: app/gitweb![uWSGI] getting INI configuration from /usr/share/uwsgi/conf/default.ini May 27 13:12:50 badger uwsgi[608]: [uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/mailman.ini May 27 13:12:50 badger uwsgi[608]: Sun May 27 13:12:50 2018 - !!! uWSGI process 1500 got Segmentation Fault !!! May 27 13:12:52 badger spamd[556]: spamd: connection from localhost [::1]:47534 to port 783, fd 5 Second, by manually running the daemon, like so: UWSGI_DEB_CONFNAMESPACE=app UWSGI_DEB_CONFNAME=expensely uwsgi --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/gitweb.ini I was able to see the segfaults first hand. gdb (in follow-child mode) and valgrind were not much help, showing a crash in uwsgi_fork, which was ostensibly returning to an invalid address. As a lucky guess, I disabled autoload=true in the default config, and that cured the segfaults--even if I don't understand why. That's the second issue I'm reporting. I have the python, python3 and cgi plugins installed. Andreas -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages uwsgi depends on: ii uwsgi-core 2.0.15-11 uwsgi recommends no packages. uwsgi suggests no packages. -- Configuration Files: /etc/default/uwsgi changed: RUN_AT_STARTUP=yes VERBOSE=yes PRINT_CONFNAMES_IN_INITD_SCRIPT_OUTPUT=yes INHERITED_CONFIG=/usr/share/uwsgi/conf/default.ini -- no debconf information
