Beiträge von Bensen

Ich habe gerade herausgefunden, dass die Konfiguration der Kinderprozesse zusätzlich in der www.conf gesetzt waren und somit wohl überschrieben wurden. Diese habe ich nun angepasst und es scheint soweit zu laufen. Ich muss mal in den Backups schauen ob diese Werte schon früher gesetzt waren und wenn ja wie hoch dieser war, weil kurios ist die Sache schon irgendwie

Habt Ihr eventuell Erfahrung mit der Konfiguration der Kinderprozesse unter php-fpm und könnt mir eventuell sagen ob die unten stehenden Werte soweit in Ordnung sind? Der Webserver stellt nur eine nextcloud Instanz und diverse kleinere PHP-Scripte bereit und hat im Allgemeinen kaum etwas zu tun.

pm = dynamic
pm.max_children = 50
pm.start_servers = 12
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 1000

Zitat von vmk

Du hast den Server komplett neugestartet? Läuft der php-Prozess im Hintergrund wirklich bis zum Timeout laut ps?

Ich habe den Server vorhin neugestartet: Fährt sauber hoch und alle Prozesse starten auch erstmal sauber. Jedoch kommt es nach wie vor zum timeout.

Meinst du mit ps folgende Ausgabe oder eine andere?

Zitat von ps aux | grep php-fpm

root 685 0.0 0.2 289404 37308 ? Ss 14:22 0:00 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)

www-data 955 0.0 0.1 290128 27584 ? S 14:22 0:00 php-fpm: pool www

www-data 956 0.0 0.1 290116 26768 ? S 14:22 0:00 php-fpm: pool www

www-data 979 0.0 0.1 290128 26008 ? S 14:22 0:00 php-fpm: pool www

www-data 982 0.0 0.1 290128 25968 ? S 14:22 0:00 php-fpm: pool www

www-data 1004 0.0 0.1 290128 26016 ? S 14:23 0:00 php-fpm: pool www

Alles anzeigen

Mahlzeit,

Gestern habe ich PHP von 7.3.9 auf 7.3.10 aktualisiert (Debian Buster, die PHP configs wurden beim update nicht überschrieben) und seit dem erhalte ich bei allen PHP Anwendungen vom nginx einen "504 Gateway Time-out". Selbst ein simples <?php echo "running"; ?> resultiert in einem timeout....

In allen nginx error Logs steht:

Zitat

upstream timed out (110: Connection timed out) while reading response header from upstream

recv() failed (104: Connection reset by peer) while reading response header from upstream (Dieser Fehler tritt nur vereinzelt auf)

Der timeout ist hier standardmäßig auf 300 Sekunden eingestellt, diesen zu erhöhen sehe ich im Anbetracht dessen ein echo schon in einem timeout resultiert als sinnlos an. Nginx / php-fpm wurden schon neugestartet was jedoch keinen Erfolg brachte.

PHP selbst sagt:

Zitat

[pool www] server reached pm.max_children setting (5), consider raising it

pm.max_children habe ich per php-fpm.conf angehoben bzw. neu erstellt, jedoch auch hier kein Erfolg (gleiche Fehlermeldung)

systemctl gibt folgenden Status aus:

Zitat von php

php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager

Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; enabled; vendor preset: enabled)

Active: active (running) since Thu 2019-10-10 12:50:45 CEST; 3min 2s ago

Docs: man:php-fpm7.3(8)

Main PID: 690 (php-fpm7.3)

Status: "Processes active: 5, idle: 0, Requests: 5, slow: 0, Traffic: 0req/sec"

Tasks: 6 (limit: 4915)

Memory: 68.1M

CGroup: /system.slice/php7.3-fpm.service

├─ 690 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)

├─ 962 php-fpm: pool www

├─ 963 php-fpm: pool www

├─ 991 php-fpm: pool www

├─ 992 php-fpm: pool www

└─1051 php-fpm: pool www

Okt 10 12:50:41 RS2000 systemd[1]: Starting The PHP 7.3 FastCGI Process Manager...

Okt 10 12:50:45 RS2000 systemd[1]: Started The PHP 7.3 FastCGI Process Manager.

● phpsessionclean.timer - Clean PHP session files every 30 mins

Loaded: loaded (/lib/systemd/system/phpsessionclean.timer; enabled; vendor preset: enabled)

Active: active (waiting) since Thu 2019-10-10 12:50:39 CEST; 3min 8s ago

Trigger: Thu 2019-10-10 13:09:00 CEST; 15min left

Okt 10 12:50:39 RS2000 systemd[1]: Started Clean PHP session files every 30 mins.

Alles anzeigen

Zitat von nginx

nginx.service - nginx - high performance web server

Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)

Active: active (running) since Thu 2019-10-10 12:59:45 CEST; 14min ago

Docs: http://nginx.org/en/docs/

Process: 1114 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS)

Main PID: 1116 (nginx)

Tasks: 5 (limit: 4915)

Memory: 5.2M

CGroup: /system.slice/nginx.service

├─1116 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf

├─1117 nginx: worker process

├─1118 nginx: worker process

├─1119 nginx: worker process

└─1120 nginx: worker process

Okt 10 12:59:45 RS2000 systemd[1]: Starting nginx - high performance web server...

Okt 10 12:59:45 RS2000 systemd[1]: Started nginx - high performance web server.

Alles anzeigen

Als nächstes würde ich die PHP Version auf 7.3.9 zurückspielen (geht das überhaupt so einfach?) aber bevor ich das tue wollte ich Fragen ob jemand eventuell eine Lösung oder eine Vermutung hat wo das Problem begraben liegen könnte.

verschoben -> https://forum.netcup.de/admini…php-504-gateway-time-out/

Zitat von Lukay

Ich besitze zwar kein Webhosting, dachte aber immer, dass der Mysql auf einem anderen Server liegt?
-h <serverip>

Ja moin...... genau da lag der Fehler

merci

Ich probiere gerade auf einen Webhosting 2000 Tarif per shell ein SQL Backup zu importieren:

mysql -u k00000_user -p k00000_db < backup_1909291729.sql

nach der Passwortabfrage kommt folgende Fehlermeldung:

Zitat

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")

Die Fehlermeldung bringt mich, gerade im Bezug auf das es sich her um ein Webhosting Tarif handelt, nicht wirklich weiter. Nutzt ihr eventuell andere Möglichkeiten SQL Backups per shell zu importieren oder könnt mir nen Tipp geben wie ich obigen Fehler beseitigen kann?

Zitat von pgloor

Nachdem ich soweit alles hinbekommen habe, funktionierte am Ende genau das NickServ Plugin immer noch nicht. Vielleicht guck ich mir das später nochmals an, aber nach der Installation von TheLounge sehe ich keinen Grund mehr dafür.

Okay, falls doch schau mal ob du das Plugin auch geladen hast -> /znc LoadMod nickserv

Lang ist es her die IRC Zeit

Zitat von pgloor

Ich habe gestern und heute versucht HexChat auf meinem PC mit Ubuntu 18.04 in Kombination mit ZNC auf einem vServer mit Ubuntu 18.04 zu installieren und zu konfigurieren, bringe das Ganze aber irgendwie nicht richtig zum Laufen.

Was genau läuft den nicht? Welche Version von ZNC benutzt du aktuell?

Zitat von pgloor

Zur Zeit funktioniert ein automatisches NickServ noch nicht, obwohl ich in den Network Einstellungen unter Modules nickserv markiert und das Passwork gesetzt habe. Langsam verliere ich die Geduld.

Meinst du die Authentifizierung mit NickServ? Ich meine hierzu gab es früher ein Plugin für ZNC (jupp gibt es -> NickServ - ZNC) somit entfällt die Client seitige Authentifizierung.

Youtube: Inside Anexia: Mass-Hosting aus Karlsruhe

sicherlich für den ein oder anderen ganz Interessant.

Zitat von pucxom

Es tut mir leid aber das ließt sich wie der Dialog zwischen mir meiner Nichte (6)...

Zitat von Lupino

Frei nach der Divise "never change a running system" update ich schon mehr oder weniger regelmäßig, (so wie heute, wo es gründlich daneben gegangen ist...) aber nicht so häufig, wie man vielleicht sollte. Meistens haben sich von irgendwelchen Paketen die Config-Parameter geändert oder irgendein Sub-Prozess des Mailservers hat eine neue Abhängigkeit, o.ä.. Oft sind es auch Abhängigkeiten von neuer Software, die ich zu installieren versuche, die mit bestehenden Paketen im Konflikt stehen.

Welche Linux Distributionen (inkl. der Version) bzw. Betriebssystem setzt du auf deinem vServer ein?

Zitat von Lupino

Hallo

ich habe das Problem dass nach einem missglückten Update der dpgk-Prozess das Neustarten des Servers blockiert. Da der Versuch des Stoppens des Servers auch den ssh-server gestoppt hat, komm ich auch nicht mehr mit ssh an den Server ran um den Prozess zu stoppen. Gibt es noch eine andere Möglichkeit, den Prozess zu beenden und den vServer zu rebooten?

Code

root     19316  0.0  0.3  22508  3564 ?        D    08:24   0:00 dpkg --configure -a

Als allererste solltest du im SCP Mal schauen ob du deinen Server über die dortige VNC Console erreichen kannst.

Zitat von Lupino

Ähm. ich hab Zugang über das VCP; komm ich an das SCP trotzdem ran?

Dann hast du noch einen vServer der älteren Generation und kannst diesen auch nur per VCP administrieren (das SCP ist den neueren Generation vorbehalten).

Da ich das VCP nicht kenne, kann ich ab hier leider nicht mehr weiterhelfen

Zitat von Lucan

Zusammenfassend: Es funktioniert nach wie vor nichts, der Support macht einen inkompetenten Eindruck und widerspricht sich selber.

Das ist sehr schade das der Support hier anscheinend 2 komplett unterschiedliche Aussagen getroffen hat. Ich denke für solche Fälle ist die Beschwerdestelle von netcup der richtige Weg (der Link befindet sich am unteren Ende in jeder gesendeten Mail vom Support).

Zitat von whoami0501

Und dann haben wir wieder einen öffentlichen Torrent, wo irgendwelche Filme, P*rnos oder sonstwas illegal geteilt werden.

Des hatten wir alles schon. xD

Stimmt, da er gerade seinen Hostname gepostet hat könnte es kritisch werden

Zitat von tab

Hmm, wo hatte ich noch gleich das Popcorn?

Schau mal unterm Schreibtisch nach, meist liegen immer noch ein paar Krümel.

P.S. Eigentlich sollte man so etwas komplett ignorieren... naja mal schauen was da heute noch so raus resultiert.

Zitat von whoami0501

Ein Server ist kein Spielzeug, sondern aufgrund der 1GBit/s Anbindung eine Waffe im Internet.

Ach komm hör auf, er will doch nur im Internet surfen.

Zitat von Vene

Wie kann ich das Problem lösen?

Probiere mal Options +FollowSymLinks durch Options +SymLinksIfOwnerMatch zu ersetzen

Es gibt wieder eine akualiesierte putty Version (vom 29.09.2019) -> https://www.chiark.greenend.or…/putty/releases/0.73.html

Zitat von putty 0.73 Changelog

• Security fix: on Windows, other applications were able to bind to the same TCP port as a PuTTY local port forwarding.
• Security fix: in bracketed paste mode, the terminal escape sequences that should delimit the pasted data were appearing together on one side of it, making it possible to misidentify pasted data as manual keyboard input.
• Bug fix (possibly security-related): an SSH-1 server sending a disconnection message could cause an access to freed memory.
• Bug fix: Windows Plink would crash on startup if it was acting as a connection-sharing downstream.
• Bug fix: Windows PuTTY now updates its terminal window size correctly if the screen resolution changes while it's maximised.
• Bug fix: tweaked terminal handling to prevent lost characters at the ends of lines in gcc's coloured error messages.
• Bug fix: removed a bad interaction between the 'clear scrollback' operation and mouse selection that could give rise to the dreaded "line==NULL" assertion box.

Zitat von Weizenfuchs

Der eigentliche Plan, ist es ein Composer update mit einer lokalen composer.phar auszuführen [...]

Eventuell hilft dir dieses Script dabei: Composer Installieren

Zitat von Weizenfuchs

Hallo Bensen, tatsächlich nutze ich php 7.2 und habe so auch den Webserver eingestellt, die php files sind auch alle vorhanden.

Ich bin auch direkt in den Ordner gegangen und habe versucht ./php auszuführen, jedoch besteht der gleiche Fehler.

Wenn der Webserver und somit auch Shopware mit PHP7.2 laufen, sollte man in der Schell auch mit 7.2 arbeiten (/usr/local/php72/bin/php).

Wie und mit welchen Befehl rufst du Shopware den genau auf, wodurch der von dir oben genannte Fehler Auftritt?

Zitat von Weizenfuchs

[...] direkten Pfad an ("/usr/local/php72/bin/").

Der korrekte Pfad lautet hier: /usr/local/php73/bin/php oder war dies nur ein Schreibfehler und der Fehler besteht weiterhin?

Nutzt dein Webserver auch die PHP7.3 Version oder eine andere?