QGIS » QGIS Application

Peter Meier wrote:

Using the qgis_mapserv.fcgi.exe through Apache 2.4 on Windows. WMS GetPrint call works on all map composer items except for the label item.
Apache log has "End of script output before headers: qgis_mapserv.fcgi.exe" and returns 500 Internal Server Error when a label item is in the map.
Same issue on 32bit and 64bit of QGIS server. Error also happens on all formats (pdf, png etc).

Same Problem on Ubuntu 16.04 LTS with QGIS 2.18.10 with text boxes (normal or html).

Thanks João Gaspar for the zip file. The QGIS Server log file is a little bit brief, Can you add the QGIS log file ?

René-Luc ReLuc wrote:

Thanks João Gaspar for the zip file. The QGIS Server log file is a little bit brief, Can you add the QGIS log file ?

Hi René Luc,
just tried with LM 3.1.3 and the demo Montepellier project on Ubuntu Xenial and QGIS Server 2.18.11 installed from QGIS.org repos.

Trying do a getprint (I used LM to be easily replicable for everyone) from within the Montpellier demo project, with the provided layout then the process fails (500) and in Apache log I see

[Mon Aug 07 21:56:24.637599 2017] [fcgid:warn] [pid 25688] [client 127.0.0.1:45236] mod_fcgid: error reading data, FastCGI server closed connection
[Mon Aug 07 21:56:24.637635 2017] [core:error] [pid 25688] [client 127.0.0.1:45236] End of script output before headers: qgis_mapserv.fcgi
[Mon Aug 07 21:56:26.720550 2017] [fcgid:error] [pid 6684] mod_fcgid: process /usr/lib/cgi-bin/qgis_mapserv.fcgi(25692) exit(communication error), get signal 11, possible coredump generated

As soon as I downgrade to 2.14.17 it works as expected.

Does the issue still exist in 2.18 ?
I have tested the dummy project with 2.18.13 and no segfault.

Hi,

I can confirm this bug on QGIS LTR 2.18.13 and Ubuntu server. Print composer without text label (map, legend, scale) works OK, but when you add simple text label then you get Server Error. Apache log is same as above.

Switching back to 2.14.x works normally.

regards,
Uroš

Have you the QGIS and QGIS Server log ?

René-Luc ReLuc wrote:

Have you the QGIS and QGIS Server log ?

I did a complete fresh install on Ubuntu xenial, used QGIS 2.18.13 from QGIS repos + ubuntugis dependencies.
After setting up the fake xserver I'm able to print almost without issues > print works (no 500 error) but raster layers are printed above all the rest, despite the order set in QGIS project (also tried the "layer order" functionality) and LM plugin.

The layer order in the URL has changed between 2.14 and 2.18.

And with a fake server X, no segfault ?

René-Luc ReLuc wrote:

The layer order in the URL has changed between 2.14 and 2.18.

I tested the Montpellier demo from LM 3.1.4 (I added a raster layer in the project to test that).
What should we change to get the raster layers printed in the correct order?

And with a fake server X, no segfault ?

apparently not anymore, when I tried a while ago (#15440-8) it was seg faulting despite the fake xserver being correctly setup. Note: I had to setup the fake xserver despite testing on a Desktop installation of xenial, not a headless server installation.

Giovanni Manghi wrote:

René-Luc ReLuc wrote:

The layer order in the URL has changed between 2.14 and 2.18.

I tested the Montpellier demo from LM 3.1.4 (I added a raster layer in the project to test that).
What should we change to get the raster layers printed in the correct order?

In LM config you have to specify the QGIS Server version to have the right order.

René-Luc ReLuc wrote:

Giovanni Manghi wrote:

René-Luc ReLuc wrote:

The layer order in the URL has changed between 2.14 and 2.18.

I tested the Montpellier demo from LM 3.1.4 (I added a raster layer in the project to test that).
What should we change to get the raster layers printed in the correct order?

In LM config you have to specify the QGIS Server version to have the right order.

oh sorry, completely forgot about that.

René-Luc ReLuc wrote:

Does the issue still exist in 2.18 ?
I have tested the dummy project with 2.18.13 and no segfault.

I just tried also on Windows (with QGIS Server installed from osgeo4w) and the issue is confirmed: crashes when printing (with labels) with 2.18 and is ok with 2.14.

René-Luc ReLuc wrote:

Does the issue still exist in 2.18 ?
I have tested the dummy project with 2.18.13 and no segfault.

see also this comment: https://github.com/qgis/QGIS/pull/5413#issuecomment-338619514

I have testing n the same server : the package provided by qgis.org and my own build.

The package segfault, not the build!

René-Luc ReLuc wrote:

I have testing n the same server : the package provided by qgis.org and my own build.

The package segfault, not the build!

good catch!

René-Luc ReLuc wrote:

I have testing n the same server : the package provided by qgis.org and my own build.

The package segfault, not the build!

Hi,
What does that mean. Is this solved?

thanks,
Uroš

Uroš Preložnik wrote:

René-Luc ReLuc wrote:

I have testing n the same server : the package provided by qgis.org and my own build.

The package segfault, not the build!

Hi,
What does that mean. Is this solved?

it means that the binaries available from the official "channels" (linux repositories, osgeo4w, etc.) are compiled in a way that they have/show the issue. If you compile yourself the code then is ok, probably because in the default compile options some flag is not used (but is used by who created official packages).

Giovanni Manghi wrote:

it means that the binaries available from the official "channels" (linux repositories, osgeo4w, etc.) are compiled in a way that they have/show the issue. If you compile yourself the code then is ok, probably because in the default compile options some flag is not used (but is used by who created official packages).

Thanks for explaining. I understand from developers point of view this is solved issue, but from users perspective? I mean what to do to get this working in official package in next point release?

We (QGIS community) need solid working QGIS server LTR for production sites.

Thanks for explaining. I understand from developers point of view this is solved issue, but from users perspective? I mean what to do to get this working in official package in next point release?

We (QGIS community) need solid working QGIS server LTR for production sites.

no, it is not solved at all. In fact is a long time that I try to raise some attention to this issue without much success. Now that 2.18 will become really the new LTR I believe that more people will hit this road block and so it will get more traction.

Giovanni Manghi wrote:

no, it is not solved at all. In fact is a long time that I try to raise some attention to this issue without much success. Now that 2.18 will become really the new LTR I believe that more people will hit this road block and so it will get more traction.

That's quite a problem, meaning 2.18 can't be used in production. And 2.14 latest has its own issue with WFS reported here #17606 and also can't be used if you need WFS. So for production we're stuck with 2.14.16 and not be able to update.

If someone will have chance maybe can be discussed in developers meeting happening now in Madeira. I know it's much more exciting to develop new features, but the reason for LTR was very clear. First and most important thing is that you have stable release.

hint: crashes here on debian unstable with QT_GRAPHICSSYSTEM=opengl, but not with raster or native.

Jürgen Fischer wrote:

hint: crashes here on debian unstable with QT_GRAPHICSSYSTEM=opengl, but not with raster or native.

How to fix it ?

I can't reproduce the issue on the same server with 2.18.17 package.
Does the issue still exist ?

René-Luc ReLuc wrote:

I can't reproduce the issue on the same server with 2.18.17 package.
Does the issue still exist ?

I can confirm issue exists on 2.18.17. I'm using LTR repository for Debian https://qgis.org/debian-ltr on Linux Mint and updated from 2.18.13 and issue remains. Problem is the same as described above. Print composer with text label generates server error on GetPrint request. If I run only map and legend works.

After some discussion with one of the main QGIS Server developers (Alessandro) I updated the description.

With QGIS Server 3 there is no crash on GetPrint... but it seems to suffer of several other issues (regressions) compared to 2.*. I will file them in separate tickets. The most important one seems to be the speed (much slower).

Note: the only way I found to make QGIS Server 3 work on Win was use this method: http://level2.si/2018/03/qgis-server-3-0-on-windows-10/

If we assume that QGIS Server 3.4 will be at least on par with 2.* and that the source of this issue found (and a fix done) it remain the fact that until at least next fall QGIS Server ltr on Windows is missing arguably one its most important features.

Giovanni Manghi wrote:

No one (as far as I understand) will look at this because a) on Linux has a clear "workaround" and b) on QGIS 3 does not happen.

The related Linux issue needs some clarification on what is the clear "workaround". I don't understand and I couldn't make it worked. I posted more description there.

This would be fine to say OK, you should use QGIS 3 but is it so simple? You wrote earlier there are other issues, I didn't test fully QGIS Server 3. When I will I will publish it on site level2.si.

It's not OK to have LTS release not working and only response is, well you should be using QGIS 3.

Uroš Preložnik wrote:

Giovanni Manghi wrote:

No one (as far as I understand) will look at this because a) on Linux has a clear "workaround" and b) on QGIS 3 does not happen.

The related Linux issue needs some clarification on what is the clear "workaround". I don't understand and I couldn't make it worked. I posted more description there.

This would be fine to say OK, you should use QGIS 3 but is it so simple? You wrote earlier there are other issues, I didn't test fully QGIS Server 3. When I will I will publish it on site level2.si.

It's not OK to have LTS release not working and only response is, well you should be using QGIS 3.

I understand and agree. QGIS Server 2.18 should work on Windows as it did the previous LTR (2.8 and 2.14). Something changed (possibly something on how the code is compiled rather than a regression in the code), the proof is that also on Desktop Linux (tested Ubuntu here) the behavior also changed meaning that up until 2.14 was not needed to install a fake xserver (something that on a real server is always expected to be necessary, as they are headless). The "workaround" is to install the fake xserver https://www.itopen.it/qgis-server-setup-notes/ but on Windows this is not possible (not that I know). I raised the issue a couple fo times in the dev mailing list, but this didn't get much attraction. The GetPrint call for layouts with advanced elements works on QGIS Server 3 on Windows, but a preliminary test also shown other new issues (I have yet to fully investigate them).

Giovanni Manghi wrote:

I understand and agree. QGIS Server 2.18 should work on Windows as it did the previous LTR (2.8 and 2.14). Something changed (possibly something on how the code is compiled rather than a regression in the code), the proof is that also on Desktop Linux (tested Ubuntu here) the behavior also changed meaning that up until 2.14 was not needed to install a fake xserver (something that on a real server is always expected to be necessary, as they are headless). The "workaround" is to install the fake xserver https://www.itopen.it/qgis-server-setup-notes/ but on Windows this is not possible (not that I know). I raised the issue a couple fo times in the dev mailing list, but this didn't get much attraction. The GetPrint call for layouts with advanced elements works on QGIS Server 3 on Windows, but a preliminary test also shown other new issues (I have yet to fully investigate them).

Thank you for your effort. I will try to test QGIS 3 and also enable fake xserver on Linux. I just do not understand why do you mean is not needed to install this on production Linux server. Its' normal for Linux to have only server instance (bash) without any GUI and it's working on 2.14.

Having the same issue on Windows with IIS as web application server: Printing in 2.14 works, printing in 2.18 not.
The environment variable DISPLAY=99 solves the problem also on Windows with IIS.

GetPrint and all other Server Requests do not run on Windows using the OSGEO4W installation of Version 3.4.4-1. There must be more problems than the dummy DISPLAY variable.

Martin Huber wrote:

GetPrint and all other Server Requests do not run on Windows using the OSGEO4W installation of Version 3.4.4-1. There must be more problems than the dummy DISPLAY variable.

so qgis server 3.4.4 is completely broken on Windows?

Yes, I also noticed that and file another #20873 some time ago. Maybe better to discuss it there.

Martin Huber wrote:

Having the same issue on Windows with IIS as web application server: Printing in 2.14 works, printing in 2.18 not.
The environment variable DISPLAY=99 solves the problem also on Windows with IIS.

sorry for the dumb question, how to set the DISPLAY variable on Windows?

Ciao Giovanni

This is not a dumb question, because you will not find a single description in the whole zillions of web-pages telling you how to install QGIS Server on IIS.

Here the secret #1: add the qgis server executable as a FastCGI application to the root node of your IIS
secret #2: for a FastCGI application you can set environment variables -> also the DISPLAY
secret #3: create a landing point for your QGIS server request with a handler assignment deviating the call to the qgis server executable
This works if you manage all other IIS stuff like the permissions for the application pool etc.

If you have further questions, we should discuss this separately ([email protected]).

Tanti saluti

Martin

Martin, you can probably update the QGIS documentation !

On windows, the documentation only specified Apache from Osgeo4W, no information about IIS: https://docs.qgis.org/testing/en/docs/user_manual/working_with_ogc/server/getting_started.html#installation-on-windows

About the documentation about Apache can also updated.

René-Luc, please give me the link to the doc-source and I'll do it as soon as I have some time.

Martin Huber wrote:

René-Luc, please give me the link to the doc-source and I'll do it as soon as I have some time.

I would say here: https://github.com/qgis/QGIS-Documentation/tree/master/source/docs/user_manual/working_with_ogc/server

Martin Huber wrote:

Ciao Giovanni

This is not a dumb question, because you will not find a single description in the whole zillions of web-pages telling you how to install QGIS Server on IIS.

Here the secret #1: add the qgis server executable as a FastCGI application to the root node of your IIS
secret #2: for a FastCGI application you can set environment variables -> also the DISPLAY
secret #3: create a landing point for your QGIS server request with a handler assignment deviating the call to the qgis server executable
This works if you manage all other IIS stuff like the permissions for the application pool etc.

If you have further questions, we should discuss this separately ([email protected]).

thanks!

@Martin Huber, out of curiosity, what part of the information you wrote is specific to QGIS and what part may apply to any FastCGI deployment on IIS?

Alessandro Pasotti wrote:

@Martin Huber, out of curiosity, what part of the information you wrote is specific to QGIS and what part may apply to any FastCGI deployment on IIS?

It is all on efficient (but not necessarily obvious) FastCGI deployment on IIS which is needed to set all the environment parameters like DISPLAY that QGIS server requires to run on IIS. And these are only the core steps when all the other IIS settings and module activations are done. Do you have a link describing that step by step somewhere?

like DISPLAY that QGIS server requires to run on IIS

it is probably also needed when using Apache (otherwise getprint will not work). Maybe this thicket is not relevant anymore as is for 2.18, but anyway this issue was a road block to the adoption of qgis server for many who are using Windows servers.

Giovanni Manghi wrote:

like DISPLAY that QGIS server requires to run on IIS

it is probably also needed when using Apache (otherwise getprint will not work). Maybe this thicket is not relevant anymore as is for 2.18, but anyway this issue was a road block to the adoption of qgis server for many who are using Windows servers.

I can confirm that setting the environment variable also solves this issue on apache64/qgis 2.18.20 64bit/windows server 2012

FcgidInitialEnv DISPLAY ":99"