[pkg-uWSGI-devel] Bug#900273: closed by Thomas Goirand <zigo at debian.org> (Re: Bug#900273: uwsgi: Segmentation fault with autoload = true)

[Andreas Kloeckner]

"Debian Bug Tracking System" <owner at bugs.debian.org> 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 <zigo at debian.org>.
>
> 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 <zigo at debian.org> by
> replying to this email.
>
>
> -- 
> 900273: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900273
> Debian Bug Tracking System
> Contact owner at bugs.debian.org with problems
> From: Thomas Goirand <zigo at debian.org>
> Subject: Re: Bug#900273: uwsgi: Segmentation fault with autoload = true
> To: 900273-done at 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