die virtuellen CPUs anders konfiguriert sind.
Kann man das als Kunde selbst feststellen, z.b. via dmidecode etc.?
die virtuellen CPUs anders konfiguriert sind.
Kann man das als Kunde selbst feststellen, z.b. via dmidecode etc.?
dann würde doch das 32-bittige debian nicht laufen.
edit: zu langsam…
schreib bitte an tab in einer PM (in »Konversationen«) deine domains, die du jetzt im besitz hast und jene, die du noch haben willst oder was immer du auch ändern willst.
Wie erstelle ich zum Beispiel direkt Domains und was kostet es
https://www.netcup.com/de/domains/domain-kaufen
Sorry muss mich wieder neu in alles einarbeiten
ich würde dir eins der flatfile CMS empfehlen, wie
bludit.com
cmsimple.org
getgrav.org
oder
flatpress.org
Mit so wenig Informationen kann man wirklich nichts anfangen.
Evtl. könntest du umreissen, welche Funktion und Größenordnung die Site(s) haben soll(en).
Ggf. werden die Zeitverzögert gesendet?
Leider nein, oder zum Glück. Zu GMX trudelt alles mit maximal 1-2 Minuten Verzögerung ein.
Die letzten real-events an Gmail waren im März und seitdem Funkstille.
Wobei ich natürlich nicht prüfen kann, seit wann nichts mehr durchkommt, weil evtl. auch nichts triggern musste.
Mail generell ist einfach nur kaputt, IMHO. Ich hätte einfach gerne eine XMPP/Telegram-Send-Funktion im Plesk.
Im Zuge des php-killer-Threads stieß ich auf das Problem der Nichtzustellung von cron-job-Benachrichtigungen an zwei meiner gmail-Konten.
Hat noch jemand das gleiche Problem oder evtl. Lust das kurz zu prüfen? *
* Zeitgesteuerte Ausführung ist nötig – »Jetzt ausführen« schickt keine mails.
Im aktuellen DNS 2x ja.
Im neuen CloudDNS (beta) kannst du dann die TTLs pro record einstellen.
Auch beim verschieben auf einen anderen Host bleiben die IPv4 und das IPv6-Netz identisch.
In einem meiner Webhostings heißt der Cronjob-Prozess php und lässt sich von einem Web-PHP-Script mit exec('killall php') beseitigen.
stimmt. getestet mit einem cron-php welches exec('sleep x') startet und php wird korrekt gekillt.
der gespawnte sleep läuft aber weiter bis ende. es kommt also darauf an, was man konkret laufen hat.
Lösung 1: PID vom wildlaufenden prozess 'psax'-en (#16) und killen.
Lösung 2: siehe #26
jedenfalls sieht man die cron-job-initiierten prozesse mit exec('ps ax'); und kann über die pid selbige auch im terminal killen (kill ist dort vorhanden).
# plesk-cron-job df-check mit gespawntem sleep 30
[3] => 2735396 ? S 0:00 bash /.local/bin/df-check
[4] => 2735416 ? S 0:00 sleep 30
terminal:
kill 2735416
->
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.
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
)
oder alle PHP-Prozesse manuell gekillt werden...
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);
?>
Alles anzeigen
* siehe #21, #22, #24 und #26
As both parties are/is "YOU", it IMHO couldn't even be a legal issue... I can burgle into my home as long as I want
But we are not owning, we are renting services and infrastructure.
The TS should clarify his demands directly with netcup.
das dürfte mit einer weiteren IPv4 und interface label -> fetchmail --interface »iface/weitere-IPv4« zu erschlagen sein.
Ginge notfalls aber auch so als Antwort: 💚, 👍, 👎, 👑..
😼
genau – wo wir doch neulich erst gelernt haben, wie man die emoji-kiste per hotkey aufmacht…💥