search

contao / contao-manager

Contao Manager
GNU Lesser General Public License v3.0
86 stars 33 forks source link

Process terminated with exit code 255 (Domainfactory) #133

Closed Samson1964 closed 6 years ago

Samson1964 commented 7 years ago

Die Installation von Erweiterungen/Paketen ist bei Domainfactory mit dem CM nicht möglich. Nach sagen wir mal 20 Sekunden bricht der CM die Operation ab:

Using version ^2.0 for jrgregory/m17-sticky-backend-footer
/xxxx/contao4/composer.json has been updated
Loading composer repositories with package information
Updating dependencies

Process terminated with exit code 255
Reason: Unknown error

Das Problem hatten mit mir schon 4 Domainfactory-Nutzer: https://community.contao.org/de/showthread.php?67276-Contao-Manager-Fehler-255-(Domainfactory) Bei meinem ManagedServer habe ich diverse Einstellungen beim RAM versucht. Eingestellt ist auf 1 GB, aber auch mit 2 oder 3 GB kommt der Fehler. Auf der Konsole läuft die Paket-Installation problemlos durch.

agoat commented 7 years ago

Das liegt vermutlich daran, dass bei Domainfactory die RAM-Begrenzung für die über Konsole ausgeführten PHP-Skripte um den Faktor 3 höher ist. Sofern es sich hier um ein SharedHosting-Paket (ManagedHosting) handelt, können die Limits nicht geändert werden. D.h. es bringt nichts 2 oder 3GB in der php.ini zu setzen. Es ist - je nach Paket - auf zwischen 64 und maximal 256 MB begrenzt. Und der composer braucht für eine Contao-Installation fast 500MB.

Samson1964 commented 7 years ago

Bei mir handelt es sich um einen ManagedServer, wie ich schon schrieb. Was die anderen 3 Nutzer haben, weiß ich nicht. Mein Server hat 16 GB RAM und Änderungen in der php.ini sind nach Auskunft von df) sofort wirksam. Aber 3 GB haben es ja auch nicht gebracht. Muß also was anderes sein, was den Prozess beendet. Aktuell lasse ich die Domain schon seit Monaten mit 1 GB laufen, weil die Thumbnailerstellung ziemlich viel RAM frißt.

agoat commented 7 years ago

Bei mir handelt es sich um einen ManagedServer, wie ich schon schrieb

Hatte ich nicht gesehen.

Wenn PHP über Apache ausgeführt wird, muss der Apache neu gestartet werden, damit die Änderungen übernommen werden.

Aufgrund der Limits (und der Contao 4 problematik) hoste ich meine Sachen nicht mehr bei Df sondern habe einen Virtual Server. Hier habe ich 512MB eingestellt. Der composer läuft bei mir problemlos, allerdings wird PHP über Fast-CGI ausgeführt.

Aktuell lasse ich die Domain schon seit Monaten mit 1 GB laufen

Sofern die 1 GB auch durchgesetzt werden, liegt es dann vermutlich nicht an der RAM-Begrenzung.

aschempp commented 7 years ago

Ich denke nicht dass dies am RAM liegt. Bei zu wenig RAM kommt eine Out of Memory Fehlermeldung. In deinem Fall wurde der Prozess unerwartet beendet, beispielsweise weil ein Prozessüberwachungs-Tool auf dem Server merkt dass dieser "Webprozess" ohne Verbindung läuft. Bei diesen Problemen forschen wir leider noch, so richtig klar ist nicht warum es meist geht aber manchmal nicht, und jeder eine andere Meldung bekommt…

Samson1964 commented 7 years ago

Ich habe den df)-Support angeschrieben und direkt nach so einem Überwachungstool gefragt. Sie baten mich daraufhin um genauere Informationen zum Nachvollziehen des Problems. Ich habe ihnen die Zugangsdaten zum CM gegeben und das Problem detailliert beschrieben. Heute früh um kurz vor 6 kam die Antwort:

Die Datei contao-manager.phar.php verfügt leider über einen Selbstschutz, weshalb es uns sehr schwer fällt diese Fehlfunktion zu debuggen. Wir haben Ihre Domain "schachbund.de" jedoch testweise einmal auf FastCGI/FPM umgestellt und dort die intl Extension nachgeladen. Damit funktioniert die Installation und Verwendung der beschriebenen Contao 3 Erweiterung. Ist das eine praktikable Lösung für Sie?

Das mit der intl-Extension hatte ich ja schön öfter gelesen. Das mit dem PHP-Modus ist mir weniger geläufig.

agoat commented 7 years ago

Dann liegt/lag es evtl. an der TimeOut-Direktive. Vielleicht war die auf 20s eingestellt. Auch wenn der Default-Wert bei 300 liegt, ist bei manchen Installationspaketen 20 eingestellt. Nach diesem TimeOut werden alle Apache-Module (also auch PHP wenn als Module ausgeführt) terminiert. Wenn PHP über FastCGI ausgeführt wird, gilt dieses TimeOut nicht.

aschempp commented 7 years ago

Genau das von @agoat denke ich eben auch…

Samson1964 commented 7 years ago

Ich habe keine Ahnung von den PHP-Modi, aber nachdem mein Contao 3.5 mit FastCGI im Backend deutlich langsamer wurde (sh. auch Contao-Forum), habe ich das Experiment beendet. Ich hatte den Eindruck das Contao bei den Requests einfach mal für rund eine Minute in einen Dornröschenschlaf fällt.

swinde commented 7 years ago

Ich vermute das es an der PHP_CLI Version lag, da bei DF (warum auch immer) immer noch php_cli 4.4.9 standardmäßig voreingestellt ist.

Xendiadyon commented 7 years ago

Ja, es liegt z.T. an der PHP-CLI-Version. Aber nicht nur:

Die PHP_CLI-Version bei DF ist immer die 4.4.9, d.h. man muss die PHP-Version auf 7.7.1 stable EXTENDED (mit INTL) umstellen. Dann wird vom Contao-Manager die korrekte PHP-Binary gefunden: image

Nun ist aber noch das Problem, dass trotzdem noch der Error 255 auftaucht, mit der Fehlermeldung mmap() failed: [12] Cannot allocate memory image

Standardmäßig wird eine php.ini mit nur 100M memory_limit geladen. Selbst wenn man manuell eine php.ini definiert, wird die zwar im Web gefunden und benutzt, aber vom Contao-Manager (Shell übers Web-Interface sowie Shell/Kommandozeile) nicht verwendet.

Nun kann man (theoretisch) beim Laden der PHP-Binary sagen, dass man entweder eine selbstdefinierte php.ini verwenden möchte (bspw. mit memory_limit 1000M und max_execution_time 300s) :

Achtung: Die php.ini wird definitiv geladen; das hat aber tatsächlich absolut keinen Einfluss auf die max_execution_time/memory_limit bei PHP-Ausführung über die (Web-)Konsole. Hier hat Domainfactory eigene Memory bzw. RAM-Limits gesetzt, die so nicht umgangen werden können: https://community.contao.org/de/showthread.php?67276-Contao-Manager-Fehler-255-(Domainfactory) https://www.df.eu/forum/threads/81412-Contao-4-4-1-Scriptlaufzeiten https://community.contao.org/de/showthread.php?67819-Installation-%C3%BCber-Contao-Manager-quot-ManagedHosting-Medium-quot

Alternativ könnte man bei der Definition der php-Binary einfach nur das memory_limit und max_execution_time hochsetzen: ( https://community.contao.org/de/showthread.php?67276-Contao-Manager-Fehler-255-(Domainfactory) ): /usr/local/bin/php7.1.10-cli -d memory_limit=1G -d max-execution_time=900 Achtung: Auch hier werden die Daten zwar geladen, aber Domainfactory setzt trotzdem andere Ausführungszeiten/Speicherbegrenzungen an, sodass wir weiterhin den Fehler 255 bekommen. Leider also auch keine Lösung.

die Lösung - für unsere Konfiguration (managed Hosting)

Und die dritte - fachlich natürlich noch etwas anspruchsvollere - Möglichkeit ist, den Contao-Manager über die Shell auszuführen. Wichtig: Wir führen nicht den Composer direkt aus, sondern den Composer über den Contao-Manager, damit man den Contao-Manager im Web-Interface auch noch verwenden kann:

Wenn wir nicht den Contao-Manager über das Web-Interface sondern direkt über die Konsole ausführen, sind die Domainfactory-Speichergrenzen nicht ganz so restriktiv gesetzt und wir haben reichlich Serverzeit, um alle update/cache/require-Anweisungen auszuführen. Kann aber sein, dass die Speichergrenzen für uns schon hochgesetzt wurden.

Kurz: So funktioniert es (für uns), es ist aber leider ziemlich umständlich. Vielleicht kommen wir ja irgendwie an einen Fix für alle Domainfactory-Kunden?

leofeyer commented 7 years ago

@Xendiadyon Vielen Dank für diese ausführliche Analyse!

aschempp commented 7 years ago

Vielen Dank für die ausführliche Analyse! Die Binary solle in Beta10 eigentlich automatisch gefunden werden, den Pfad für Domainfactory haben wir hinterlegt: https://github.com/contao/contao-manager/blob/develop/api/Resources/config/providers.yml#L40

Es gibt sogar die Möglichkeit für einzelne Provider eine spezielle Konfiguration zu laden (Beispiel: https://github.com/contao/contao-manager/blob/develop/api/Resources/config/providers.yml#L23). Nur wie du selber erklärst nützt das bei Domainfactory wohl nichts. Gegen deren Server-Limiten nützt das alles nichts. Falls jemand einen Kontakt zum Support hat (und vielleicht nicht First-Level) dann würde ich das gerne mit denen klären.

Xendiadyon commented 7 years ago

Ich nehme mal @ADoebeling mit dazu :)

Xendiadyon commented 7 years ago

Kurze Anmerkung: Die Fehlermeldung mmap() failed: [12] Cannot allocate memory kommt bei uns 15 Sekunden nach Starten des Update-Prozesses.

swinde commented 7 years ago

@aschempp vielleicht kannst Du ja einmal in diesem Fred ein Statment abgeben. https://www.df.eu/forum/threads/81412-Contao-4-4-1-Scriptlaufzeiten Der User Nils Dornblut ist ein DF Mitarbeiter da.

bibib commented 7 years ago

Ich hab bei der DF in einem Blogbeitrag mal einen Kommentar hinterlassen: hier

Edit: Link setzen geübt ...

aschempp commented 7 years ago

Ich habe mich im Forum registriert aber habe trotzdem keine Berechtigung etwas zu schreiben. Kannst du ihn vielleicht auf diesen Thread verweisen? Er kann mich auch gerne per E-Mail kontaktieren, das wäre sicherlich am effizientesten.

swinde commented 7 years ago

Ich habe dem Herrn Dornblut in dem Fred eine Nachricht hinterlassen, falls keine Antwort kommt kann ich Ihm auch noch eine PM schicken. In dem Forum gibt es noch einen internen Bereich für Reseller, möglich das der Beitrag da drin ist.

bibib commented 7 years ago

Ich habe ihn in meinem oben verlinkten Blogkommentar schon auf diesen Thread verwiesen.

nilsdornblut commented 7 years ago

Wir schauen uns das an und melden uns. Da wir das alles einmal nachvollziehen möchten, wird das etwas dauern.

@aschempp: Ich habe Ihren Account bei uns im Forum so angepasst, dass Sie dort nun auch Schreibrechte haben.

Grüße

Nils Dornblut im Auftrag der DomainFactory

agoat commented 7 years ago

Noch ein kleiner Hinweis als DF Kunde.

Ich hatte Contao 4 (Standard-Edition) problemlos auf einem SharedHosting Server zum laufen gebracht. Die Verwaltung über den Composer (der ja vom Contao Manager ebenfalls benutzt wird), war problemlos über SSH möglich, da hier (wie bereits oben im Kommentar schon erwähnt) die Limits für RAM und Skriptlaufzeiten um mind. den Faktor 3 höher sind. Da der Contao Manager aber über HTTP bzw. über den Apache-Server läuft, greifen hier die Limits je nach Paket (max. 256MB). Die Skriptlaufzeit wird eher nicht das Problem sein, aber das RAM-Limit. Auf meinem Root-Server sehe ich, dass das Composer-Skript über 500MB benötigt, je nachdem wie viele Pakete damit in einer Installation verwaltet werden.

D.h. der Contao-Manager wird niemals auf einem Shared-Hosting Server über HTTP funktionieren. Der normale Betrieb von Contao 4+ ist kein Problem, da Contao i.d.R. nicht mehr als 128MB an RAM benötigt. Auch der Contao-Manager läuft selbst, nur die Verwendung des Composer-Tools ist das Problem.

@aschempp Wäre es möglich aus dem Contao-Manager heraus über SSH das Composer-Tool zu starten?

swinde commented 7 years ago

Das hatte ich hier https://github.com/contao/contao-manager/issues/158 auch schon angeregt. Wobei ich den Programmieraufwand nicht einschätzen kann.

agoat commented 7 years ago

Ein Problem wäre zusätzlich noch, dass der Anwender auch noch SSH-Zugangsdaten eingeben muss (evtl. macht er das über eine unsichere Verbindung) und das macht die Anwendung schon wieder komplizierter. Der CM soll ja genau das möglichst umgehen und alles einfach machen.

So wie @aschempp in #158 geschrieben hat, wird der Composer ja bereits über CLI aufgerufen.

Ich denke das ein PHP-CLI Aufruf aus einem laufenden PHP-Task heraus etwas anderes ist, wie wenn PHP-CLI über SSH gestartet wird? Der Aufruf über SSH erfolgt ja i.d.R. auch über einen anderen Benutzer als der des Web-Servers.

aschempp commented 7 years ago

Da der Contao Manager aber über HTTP bzw. über den Apache-Server läuft, greifen hier die Limits je nach Paket (max. 256MB).

Diese Aussage ist nicht ganz korrekt. Der Manager läuft als Hintergrundprozess, daher greift das Memory-Limit der Server-Konfiguration nicht. Es gibt aber je nach Hosting-Anbieter auch Limits auf der Kommandozeile, die eben nichts mit den Einstellungen aus dem Control Panel zu tun haben.

agoat commented 7 years ago

Ja, ist nicht ganz korrekt. Allerdings würde ich als Provider den Aufruf eines Kommandozeilen-Tasks aus einem PHP-Skript auch stark limitieren, da ja ansonsten die Limits, die für die Server-Stabilität durchaus notwendig sind, umgangen werden können.

aschempp commented 7 years ago

Theoretisch. Nur gelten die Limits auf SSH ja auch nicht. Und die Limits sind in PHP nicht wegen Server-Stabilität vorgesehen, sondern falls ein Script einen Fehler macht und damit endlos läuft. Was wir natürlich nie tun würden 😝

nilsdornblut commented 7 years ago

Ich habe die Installation via Browser getestet. Mit 128 MB RAM-Limit läuft diese durch und Contao ist danach verfügbar. Natürlich müssen noch die Datenbankzugangdaten angeben werden.

Ruf man anschließend den Contao Manager für beispielsweise ein Update der Pakete auf, gibt es Probleme mit zu wenig RAM. Teilweise ging es erfolgreich mit 256 MB Limit , teilweise aber auch erst mit 512 MB. Es sei noch angemerkt, dass es sich um Einstellungen auf dem Server handelt und nicht in der php.ini (dies war unverändert bei 100MB).

Von daher ist zu empfehlen, die Installation und auch Aktualisierungen über SSH zu machen, wenn kein Managed Server oder zumindest ein größeres Paket im Shared Hosting zur Verfügung steht.

Sicher werden wir bei kommenden Tarifupdates der Punkt wieder neu überdacht, kurzfristig ist da aber leider nichts machbar. Sollten sich doch noch Änderungen ergeben, melden wir uns natürlich.

Noch eine Anmerkung/Frage: Beizieht sich diese Seite rein auf die Weboberfläche des contao-manager?

https://github.com/contao/contao-manager/wiki/Domainfactory

In jedem Fall stimmen die Infos so nicht, wie oben aufgezeigt, der Hinweis auf die Nutzung von SSH sollte in jedem Fall ergänzt werden. Auch sollte ergänzt werden, dass bei einem Managed Server die Einstellungen in Bezug auf RAM oder auch CPU-Zeit durch den technischen Support "beliebig" (bis zu den physikalischen Limits des Servers) angepasst werden können.

Grüße

Nils Dornblut im Auftrag der DomainFactory

fritzmg commented 7 years ago

Diese Aussage ist nicht ganz korrekt. Der Manager läuft als Hintergrundprozess, daher greift das Memory-Limit der Server-Konfiguration nicht.

@aschempp das stimmt so nicht, wie bereits in https://github.com/contao/contao-manager/issues/158 erwähnt. Auch wenn du die Tasks als separaten Prozess erzeugst, gelten hier je nach Hosting Umgebung immer noch Limits, die aber nichts mit den Limits auf der Kommandozeile direkt über SSH zu tun haben. Vermutlich ist bspw. der Arbeitsspeicher pro Prozess der vom Webserver gespawned wird beschränkt. Und da du den Prozess innerhalb eines Prozesses des Webservers spawnst, treffen diese Limitierungen auch hier zu.

nilsdornblut commented 7 years ago

@aschempp das stimmt so nicht, wie bereits in #158 erwähnt. Auch wenn du die Tasks als separaten Prozess erzeugst, gelten hier je nach Hosting Umgebung immer noch limits, die aber nichts mit den Limits auf der Kommandozeile direkt über SSH zu tun haben. Vermutlich ist bspw. der Arbeitsspeicher pro Prozess der vom Webserver gespawned wird beschränkt.

Genau, auch wenn sich das hartnäckig hält, ist die Sichtweise so richtig. Der Erzeuger ist ja hier der PHP-Prozess und der bzw. dessen Kinder ist limitiert bzw. wir räumen hier sozusagen immer wieder auf, wenn es um Laufzeiten geht. Es kann sein, dass man so Limits der php.ini umgehen kann in bestimmten Fällen (nicht gut, aber nicht vermeidbar). Daher ist die Implementierung auf Ebene des Webservers sicherheitstechnisch auch sehr wichtig.

Xendiadyon commented 7 years ago

Ich habe das Wiki mal aktualisiert. Ich hoffe, das ist so korrekt. https://github.com/contao/contao-manager/wiki/Domainfactory

nilsdornblut commented 7 years ago

Danke, ich habe es noch etwas präzisiert. Falls was der Gemeinde nicht gefällt, dann bitte ändern. So sollte es aber schnell eine Überblick geben, was geht und was nicht, ohne Schönfärberei.

swinde commented 7 years ago

In den "ManagedServer"-Paketen läuft der Contao Manager je nach Einstellungen mit Problemen. Sollten Probleme auftreten, kann der Eigentümer des Servers bei der Technik der DomainFactors die RAM-Einstellungen ohne Probleme und kostenfrei bis zum gewünschten Limit erhöhen lassen.

Gilt das auch für Reseller?

ADoebeling commented 7 years ago

@swinde

Gilt das auch für Reseller?

Ob du Reseller oder Endkunde bist macht keinen Unterschied. Wichtig ist nur ob SharedHosting oder Servertarif

Xendiadyon commented 6 years ago

kurzes Update: Domainfactory hat für uns die Serverzeiten hochgesetzt, damit geht es theoretisch. Allerdings hängt es ab von der PHP-Einbindung:

Domainfactory kann für uns die intl-Extension für FastCGI aktivieren. Damit klappt es dann mit der Konfiguration PHP7.1-latest FAST-CGI

Die Einbindung per EXTENDED oder STANDARD schlägt immer fehl.

Toflar commented 6 years ago

Today, we released version 1.0.0 stable. This version also ships with Composer Cloud that allows resolving of the dependencies on our servers. You can enable it in the hosting configuration. Try using it and see if that solves the issue and reopen if you still have the issue.

Wir haben heute Version 1.0.0 stable veröffentlicht. Diese Version bringt auch die Composer Cloud mit und ermöglicht die Abhängigkeitsauflösung auf unseren Servern. Sie kann bei den Hosting-Einstellungen aktiviert werden. Bitte damit erneut versuchen und Ticket wiedereröffnen, falls das Problem weiterhin besteht.

eBlick commented 6 years ago

Ich habe tatsächlich erneut dieses Problem mit der aktuellen Manager Version 1.04. Und das mit im Paket zugewiesenen 1,6G Ram. Ich habe hier auch diverse PHP Einstellungen durchgetestet, aktuell auf der 7.1STABLE. Im Manager wird der Prozess aber nur mit max 1G ausgeführt.

bildschirmfoto 2018-10-07 um 09 57 04

fritzmg commented 6 years ago

Und das mit im Paket zugewiesenen 1,6G Ram.

Damit meinst du vermutlich den PHP Prozess des Webservers. Dafür gelten meist andere Einstellungen als über das PHP CLI.

eBlick commented 6 years ago

Ja, das meine ich. Ich habe aber keinen Weg gefunden, das PHP CLI zu beeinflussen. Es handelt sich um einen Reseller Dedicated Server bei Domainfactory. Und es ist die einzige von ca. 40 Installationen, die hier Probleme macht.

fritzmg commented 6 years ago

Wende dich mit dem Problem an das Community Forum.

nilsdornblut commented 6 years ago

Das Forum ist leider noch nicht wieder in Betrieb.

Um PHP CLI zu beeinflussen muss eine php.ini mit angegeben werden, die entsprechende angepasste Limits enthält. Hier ist die Einbindung einer php.ini auf der Kommandozeile erklärt, auch wenn es speziell um Cronjobs geht:

https://www.df.eu/de/support/df-faq/webhosting/weitere-technische-faq/cronjobs/#c7204

Option "-c" muss genutzt werden für den Pfad.

aschempp commented 6 years ago

Scheint als verwendest du nicht die Composer Cloud?

eBlick commented 6 years ago

Ich habe es sowohl mit der Composer Cloud als auch mit dem DF-Server versucht. Dieselbe Fehlermeldung erhalte ich, wenn die Cloud aktiviert ist. Ich kann den Cache der Produktionsumgebung leeren. Sobald der Entwicklungscache geleert werden soll, lauf ich in den Fehler.

Toflar commented 6 years ago

Hat auch nichts mit der Cloud zu tun, es passiert beim Cache-Aufbau. Die Konsole ist scheinbar limitiert auf ca. 105 MB RAM, das ist einfach zu wenig um den Cache neu aufzubauen.

Toflar commented 6 years ago

@aschempp evtl. bei DF (https://github.com/contao/contao-manager/blob/master/api/Resources/config/servers.yml#L82) auch -d memory_limit = -1 nutzen?

eBlick commented 6 years ago

Es geht nun gleich weiter bei DF mit Problemen.

Jetzt erscheint bei einer Neuinstallation auf einem Dedicated Server (ohne Speichereinschränkungen):

mmap() failed: [12] Cannot allocate memory

in allen verfügbaren PHP Versionen

[PHP] engine = On short_open_tag = On date.timezone = "Europe/Berlin" precision = 14 y2k_compliance = Off output_buffering = Off output_handler = unserialize_callback_func = zlib.output_compression = implicit_flush = Off allow_call_time_pass_reference = On safe_mode = Off safe_mode_gid = safe_mode_include_dir = safe_mode_exec_dir = safe_mode_allowed_envvars = "PHP" safe_mode_protected_env_vars = "LD_LIBRARY_PATH" disable_functions = highlight.string = "#CC0000" highlight.comment = "#FF9900" highlight.keyword = "#006600" highlight.bg = "#FFFFFF" highlight.default = "#0000CC" highlight.html = "#000000" expose_php = On max_execution_time = 180 memory_limit = 100M error_reporting = 32759 display_startup_errors = track_errors = Off variables_order = "EGPCS" register_argc_argv = On post_max_size = 8M gpc_order = "GPC" magic_quotes_runtime = Off magic_quotes_sybase = Off default_mimetype = "text/html" doc_root = user_dir = enable_dl = On file_uploads = 1 allow_url_include = 1 extension = "intl.so" asp_tags = On allow_url_fopen = On display_errors = On log_errors = Off error_log = register_globals = On magic_quotes_gpc = On auto_prepend_file = auto_append_file = include_path = "/usr/local/lib/php_modules/7-71STABLE" upload_max_filesize = 8M extension_dir = "/usr/local/lib/php_modules/7-71STABLE" zend_optimizer.enable_loader = On zend_optimizer.optimization_level = 15 zend_extension = "/usr/local/lib/php_modules/7-71LATEST/ioncube_loader_lin_7.1.so"

[mail function] SMTP = "localhost" sendmail_from = "me@localhost.com"

[SQL] sql.safe_mode = Off

[ODBC] odbc.allow_persistent = 1 odbc.check_persistent = 1 odbc.max_persistent = -1 odbc.max_links = -1 odbc.defaultlrl = 4096 odbc.defaultbinmode = 1

[MySQL] mysql.allow_persistent = Off mysql.max_persistent = -1 mysql.max_links = -1 mysql.default_port = mysql.default_socket = mysql.default_host = mysql.default_user = mysql.default_password =

[PostgresSQL] pgsql.allow_persistent = On pgsql.auto_reset_persistent = pgsql.max_persistent = -1 pgsql.max_links = -1

[bcmath] bcmath.scale = 0

[Session] session.serialize_handler = "php" session.gc_probability = 1 session.referer_check = session.entropy_length = 0 session.entropy_file = session.cache_limiter = "nocache" session.cache_expire = 180 session.use_trans_sid = 1 url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry" session.save_handler = "files" session.save_path = "/tmp" session.use_cookies = On session.name = "PHPSESSID" session.auto_start = Off session.cookie_lifetime = 0 session.cookie_path = "/" session.cookie_domain = session.gc_maxlifetime = 1440

nilsdornblut commented 6 years ago

Das liegt wohl an den Einstellungen. Bitte das Memory Limit erhöhen in der php. ini und die Zeit gleich mit:

max_execution_time = 360 memory_limit = 500M

eBlick commented 6 years ago

Das habe ich auch bereits über die ini-Einstellungen versucht. Auch mit 1000 und mehr M. Scheint nicht anzukommen:

$ /usr/local/bin/php7.1.10-cli '-q' '/kunden/xxx-xxx/webseiten/tripnews/htdocs/web/contao-manager.phar.php' 'composer' 'install' '--prefer-dist' '--no-dev' '--no-progress' '--no-suggest' '--no-ansi' '--no-interaction' '--optimize-autoloader' 2>&1

Loading composer repositories with package information Updating dependencies

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

Process terminated with exit code 255

Result: Unknown error

eBlick commented 6 years ago

Auf diesem sowie einem weiteren Dedicated Server, den ich betreue, liefen die Erstinstallationen bislang ohne Probleme durch. Das Speicherproblem existiert erst seit knapp vier Wochen. Hat sich hier bei DF irgendetwas grundlegendes geändert?

Im Contao-Manager Wiki steht zu DF:

In den "ManagedServer"-Paketen läuft der Contao Manager je nach Einstellungen mit Problemen. Sollten Probleme auftreten, kann der Eigentümer des Servers bei der Technik der DomainFactors die RAM-Einstellungen ohne Probleme und kostenfrei bis zum gewünschten Limit erhöhen lassen. Danach lassen sich alle Erweiterungen (Bundles) updaten oder installieren. Die Einstellungen des PHP Memory-Limit sind für den Contao Manager hier ohne Wirkung, Änderungen müssen durch die Technik der DomainFactory erfolgen. Die Erstinstallation des Contao Manager inkl. aller Bundles läuft auch ohne Änderung sauber durch.Über den technischen Support der DomainFactory können die Servergrenzen bei Managed Servern wie beschrieben jederzeit angehoben werden, in der Regel ist eine Anhebung von 100 MB auf 512 MB pro Aufruf erforderlich. Dies gilt nur für die speicherintensive Installation und Update, nicht für den laufenden Betrieb.

Dazu die Fragen:

Das Forum ist leider noch nicht wieder in Betrieb.

Um PHP CLI zu beeinflussen muss eine php.ini mit angegeben werden, die entsprechende angepasste Limits enthält. Hier ist die Einbindung einer php.ini auf der Kommandozeile erklärt, auch wenn es speziell um Cronjobs geht:

https://www.df.eu/de/support/df-faq/webhosting/weitere-technische-faq/cronjobs/#c7204

Option "-c" muss genutzt werden für den Pfad.

In der Serverkonfiguration beim Manager ist mir dies so nicht gelungen.

nilsdornblut commented 6 years ago

Bitte wenden Sie sich über das Kundenmenü der DomainFactory an die Technik. Das müsste man direkt ausprobieren und schauen. Wie oben beschrieben, hatte ich da damals keine direkten Probleme.

Änderungen am Setup in der Richtung gab es nicht nach meinem Kenntnisstand. Kann aber sein, dass irgendein Seiteneffekt da vorhanden ist. Hier ist es dann gut, wenn man direkt im System schauen kann.

Samson1964 commented 6 years ago

Der Eintrag im Wiki stammt wohl von mir. Wir haben zwei ManagedServer bei df). Ohne Anpassungen des Speicherlimits durch die Technik kommst Du nicht weiter. Allerdings wundern mich die Probleme bei einer Neuinstallation. Dank Cloud-Resolver sollte Dir der Arbeitsspeicher ausreichen. Ohne Cloud-Resolver muß Dir die Technik das Limit erhöhen. Bei mir reichten 1 GB. Was in der php.ini steht, ist fast ohne Bedeutung.