View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006747 | OXID eShop (all versions) | 6. ------ Setup ------- | public | 2017-12-19 01:20 | 2024-06-05 15:53 |
Reporter | leofonic | Assigned To | |||
Priority | normal | Severity | block | Reproducibility | always |
Status | resolved | Resolution | won't fix | ||
Product Version | 6.0.0 | ||||
Summary | 0006747: Shop installation fails with error 500 at domainfactory | ||||
Description | At german hoster domainfactory, installation stops at db migration (external database command migration:migrate) with error 500. This happens because the setup sends an output to stdout. The hosting provider says this is normal behaviour because "you execute a PHP-Shellscript with cgi. The webserver is waiting for headers at this stage and therefore interprets the output as such. It is definitely not possible to push CLI-messages over CLI on our systems". | ||||
Tags | No tags attached. | ||||
Theme | Not defined | ||||
Browser | Not defined | ||||
PHP Version | Not defined | ||||
Database Version | Not defined | ||||
|
this is not a global problem for the hoster, but only occurs if the script limits in shared hosting are not sufficient, on dedicated servers the installation works without problems, even in the large packages it should fit. |
|
@gn2_netwerk: Of course this can differ from machine to machine. The cause however is not script limits but an output to stdout, as stated in the report. I couldn't find any specs what is allowed or not not allowed to send to stdout of apache's cgi process though. But i noticed that in tests this output is quieted by this line: $output->setVerbosity(ConsoleOutputInterface::VERBOSITY_QUIET); but in setup it is not. If the same is done in setup, installation runs through without problems on this shared server. https://github.com/OXID-eSales/oxideshop_ce/blob/a8cd0baa2cfc5376a7781dde4b3fc4e20021b1a8/tests/Integration/Setup/UtilitiesTest.php#L43 |
|
Thank you for your report! Unfortunately I can't reproduce this. As this case wasn't reported yet and we didn't get any other requests about that topic, it feels more like a feature request to enhance the setup process therefore it works on further server settings. For now I will leave it as a bug which is currently not reproducible. @leofonic: Can you provide us the settings from the webserver which are causing this behaviour in the setup process? Please write them in the notes or send them to [email protected] and refer to this bug entry. Thank you in advance! |
|
Unfortunately i have no info about server settings because this is not my own server, i will try to get more info. But i think this is an oxid bug from source code side, because a console output is started and messages are pushed to its output handler that do not appear anywhere, so they might as well be supressed, as it is done in the tests i quoted. |
|
If PHP is running as cgi, output to stdout is sent directly to the browser, so if there is anything sent to stdout before headers, this is interpreted as header. I tried on another shared server this time Strato, and got a similar result: 12.01.2018 15:38:30 xxx.de [client x.x.x.x] malformed header from script. Bad header= : index.php, referer: http://xxx.de/oxid_6/source/Setup/index.php |
|
I couldn't reproduce it with fastCGI either. But I leave this entry open with this improvement proposal: "But i noticed that in tests this output is quieted by this line: $output->setVerbosity(ConsoleOutputInterface::VERBOSITY_QUIET); but in setup it is not. If the same is done in setup, installation runs through without problems on this shared server. https://github.com/OXID-eSales/oxideshop_ce/blob/a8cd0baa2cfc5376a7781dde4b3fc4e20021b1a8/tests/Integration/Setup/UtilitiesTest.php#L43" See comment c0012339 |
|
@Michael yes on most systems running fcgi output to stdout is discarded, only on some not. I was not able to find the reason for this yet. |
|
Since we introduced composer as package manager you will need to use the command line for installation anyway. Please make sure that your hoster uses a configuration for CLI that returns all necessary messages from our CLI commands. |