Du kannst erst PHP deaktivieren wenn Du vorher den default Ordner mit dem default Pfad ausfüllst - sorry für die unklarheit - auf der Seite wo man PHP deaktivieren kann sind werte gelistet und ein Ordner wert ist mit default ausgefüllt und wenn man da reinklickt kann man den Pfad auswählen und wenn der statt default gelistet ist kann man das speichern und dann kann man php deaktivieren (haekchen entfernen) - ich schreib das nur weil ich gebraucht hatte um das zu kapieren als ich das erstemal php abschalten wollte.
Du kannst erst PHP deaktivieren wenn Du vorher den default Ordner mit dem default Pfad ausfüllst - sorry für die unklarheit - auf der Seite wo man PHP deaktivieren kann sind werte gelistet und ein Ordner wert ist mit default ausgefüllt und wenn man da reinklickt kann man den Pfad auswählen und wenn der statt default gelistet ist kann man das speichern und dann kann man php deaktivieren (haekchen entfernen) - ich schreib das nur weil ich gebraucht hatte um das zu kapieren als ich das erstemal php abschalten wollte.
Danke!
Ich habe die PHP-Einstellungen schon geprüft und dort deaktiviert.
Das Problem ist, dass der Prozess noch läuft und nicht beendet wird (es werden sinnlose Verzeichnisse erstellt...).
Ich hätte am liebsten sowas wie killall php.
... kannst Du irgendwas umbenennen das die Schleifen Logik von dem Script bricht ... aber loop ist loop - das geht seinen Gang
... kannst Du irgendwas umbenennen das die Schleifen Logik von dem Script bricht ... aber loop ist loop - das geht seinen Gang
Nein. Schleife läuft zuverlässig while(true)...
Wundert mich ja jetzt schon ein wenig, dass der Cronjob überhaupt ewig weiterläuft. Das wäre ja eine nette Möglichkeit, Programme dauerhaft am Laufen zu halten, was von netcup wahrscheinlich eher nicht so gewollt ist.
Wenn er sich gar nicht stoppen lässt, auch nicht z.B. mittels eines anderen PHP-Skripts, das den Prozess killt oder durch irgendwelche Einstellungen den Prozess zum Absturz bringt, dann halt Support kontaktieren.
Ist das ein zeitkritisches Problem? Läuft also z.B. der Webspace relativ zügig voll durch die Verzeichnisse oder sonstigen erzeugten Dateien? Das liesse sich eventuell über Dateirechte unterbinden, so dass dein User im entsprechenden Verzeichnis keine Verzeichnisse oder Dateien mehr anlegen darf. Oder halt ansonsten dann der Notfall-Support, wenn der normale Support nicht schnell genug erreichbar ist. Ansonsten, wenn die Quota überschritten werden, wird netcup dein Webhosting irgendwann sperren, was nicht so schön wäre.
Wieso greift denn da keine PHP Execution Time?
steht bei mir im PHP-CLI zumindest auf 0. Eventuell auch beim Cronjob, kann man ja mal auslesen lassen in einem Cronjob. Falls die max_execution_time auch noch hilft, wenn sie nachträglich gesetzt wird, dann könnte man sie über eine ".user.ini" auf eine kurze Zeit setzen - falls denn das noch nach dem Start berücksichtigt wird. Ich weiss es nicht.
Wundert mich ja jetzt schon ein wenig, dass der Cronjob überhaupt ewig weiterläuft
ich dachte der cronjob ist nur der Kickstarter - laufen tut doch jetzt nur das php script ... oder?
ich dachte der cronjob ist nur der Kickstarter - laufen tut doch jetzt nur das php script ... oder?
Klar, den Cronjob kann man ja stoppen, so dass das Skript nicht noch öfter gestartet wird. Aber das Skript läuft eben schon und darüber habe ich mich gewundert. Allerdings scheinen die PHP-Einstellungen so zu sein, dass es keine Begrenzung der Skriptlaufzeit gibt.
php-Version im WCP temporär ändern?
Dann wird php bestimmt neu gestartet und das script sollte dann eigentlich stoppen.
EDIT: Hmmm. Kann aber sein, dass das dann nur php-fpm betrifft und nicht cli
ich dachte der cronjob ist nur der Kickstarter - laufen tut doch jetzt nur das php script ... oder?
Ja. Ist nur das Skript, das läuft...
Auch habe ich die betreffende Aufgabe (cronjob) bereits deaktiviert. Und die böse .php Datei umbenannt...
Und auch PHP im WCP global deaktiviert bzw. die Version geändert... (mehrfach)
Der Prozess läuft jedoch schön stabil weiter. 
("Aufgabe... wird ausgeführt...")
P.S. Der Support war bis jetzt auch noch nicht hilfreich.
(Ich denke, der Server müsste neu gestartet werden, oder alle PHP-Prozesse manuell gekillt werden...)
PHP ist einfach eine solide Sache - das läuft 
Das wird bei mir im webhosting auch mit als erstes abgestellt weil ich nur kleine statische Seiten baue. Durch dein cleanup script verpassen wir jetzt aber den max folder benchmark oder ?
Versuche einmal die Standardsubdomain (hostingXXXXXX.YYYYY.netcup.net) in Plesk zu sperren. Cronjobs werden mit dieser Einstellung nämlich angeblich nicht mehr neu ausgeführt. Eventuell werden laufende Prozesse dadurch nach einigen Minuten ebenfalls gestoppt.
oder alle PHP-Prozesse manuell gekillt werden...
<?php
// php-killer.php
exec('killall -9 php-cgi');
?>kopiere obiges in eine datei in's root der internen nc-domain oder einer deiner domains, einmal im browser ausführen (-> error 500) und schau ob's wilde-script noch läuft. *
<?php
// psax.php
function print_er($title, $val){
echo "<pre>$title<br>";
print_r($val);
echo "</pre>";
}
//exec('kill PID', $output, $retval);
exec('ps ax', $output, $retval);
print_er("Status $retval und Ausgabe:", $output);
?>* siehe #21, #22, #24 und #26
Ich hab mal die netcup KI befragt 
Um einen laufenden Cronjob im Webhosting zu unterbrechen, der ein PHP-Skript mit einer Endlosschleife ausführt, kannst du den entsprechenden Prozess auf deinem Server beenden. Da bei Webhosting-Paketen meist kein direkter Zugriff auf die Prozesse möglich ist, solltest du den Cronjob deaktivieren oder löschen. Das kannst du im Kundencontrolpanel unter "Cronjobs" tun. Falls das nicht ausreicht oder du keinen Zugriff hast, kontaktiere bitte den Support über das Kontaktformular auf https://www.netcup.com, um dir bei der Beendigung des Prozesses zu helfen.
Meine Rede seit 66 
. Falls die Methode von Olivetti nicht funktionieren sollte - was ich befürchte, weil php-cgi jetzt nicht unbedingt nach einem Konsolenprozess klingt - empfehle ich also weiterhin den Support zu kontaktieren. Für den Support sollte das kein großes Ding sein, irgendeine(r) dort wird ja jemanden kennen, der einen kennt, der root-Rechte auf der Kiste hat und den Prozess einfach killen kann.
weil php-cgi jetzt nicht unbedingt nach einem Konsolenprozess klingt
das muss schon durch den webserver. und man hat durchaus zugriff auf »seine« prozesse (auch die im terminal / siehe unten [3] im result-Array -> nano…).
# exec('ps ax');
Rückgabe mit Status 0 und Ausgabe:
Array (
[0] => PID TTY STAT TIME COMMAND
[1] => 2541581 ? S 0:01 /usr/local/php74/bin/php-cgi -c /var/www/vhosts/system/meindingsbums.com/etc/php.ini
[2] => 2542185 pts/0 S 0:00 -
[3] => 2542255 pts/0 S+ 0:00 nano php-killer.php
[4] => 2542289 ? S 0:00 /usr/local/php83/bin/php-cgi -c /var/www/vhosts/system/hostingx.axxxx.netcup.net/etc/php.ini
[5] => 2542291 ? R 0:00 ps ax
)Ja, glaube ich schon, aber mit killall php-cgi wirst du wahrscheinlich nur die Webprozesse abschiessen, der in der Konsole dürfte wahrscheinlich anders heißen. Wenn man den richtigen Namen hat könnte es durchaus funktionieren.
Edit: Mist, ich muss mir jetzt endlich eine neue Tastatur besorgen, mit der ich nicht andauernd am korrigieren der fehlenden Buchstaben bin.
der in der Konsole dürfte wahrscheinlich anders heißen
um irgendwas in der konsole geht es doch auch gar nicht.
beim TS läuft ein ewiger plesk-cron-job und der soll weg.
sehen könnte man den ja evtl. mit exec('ps ax…');, wie in #18.