Die Seite ist nicht verfügbar

der hoster hat geantwortet das alles funktioniert, vielleicht liegt es an was anderem?

Sehen wir aus wie Idioten? Lassen Sie sie ihren eigenen Server aus dem externen Netzwerk pingen

Der Speicherplatz des Servers ging um den 2. Januar um 22:30:11 aus.

Alle Probleme deswegen.

Antwort des Hosters: Wir führen keine Arbeiten an VPS ohne Strom von der Seite des Coristuvach aus, auch nicht sauber mit den Initiativen der Behörden. Manchmal sind 39 % des Speicherplatzes auf Ihrem Server belegt. Nach Ihrem Anruf haben wir den Server neu geladen, aber die Website hat den Roboter danach nicht mehr gesehen. Kehren Sie um, seien Sie eine Liebkosung zur Unterstützung von Onebox.

Den CRM-Protokollen nach zu urteilen, trat das Problem am 3. September 2022 auf: [2022-01-03 00:09:01] Punkt: /var/www/vilescrmoneboxc/web1/web/modules/voip/cron/cron-binotel.php data : Array ( [type] => 1 [message] => Uncaught ConnectionManager_Exception: Verbindung zur Datenbank nicht möglich: Verbindung in /var/www/vilesc rmoneboxc/web1/web/packages/ConnectionManager/ConnectionManager_MySQLi.class.php:44 Stack abgelehnt Spur: #0 /var/www/vilescrmoneboxc/web1/web/packages/ConnectionManager/ConnectionManager_MySQLi... ConnectionManager_MySQLi->connect() #1 /var/www/vilescrmoneboxc/web1/web/packages/SQLObject/ SQLObject.class.php(917): ConnectionManager_MySQLi->escapeString () #2 /var/www/vilescrmoneboxc/web1/web/packages/SQLObject/SQLObject.class.php(946): SQLObject->makeWhereArray() #3 / var/www/vilescrmoneboxc/web1/web/packages/SQLObject/SQLObject.class.php(1296): SQLObject->makeWhereString() #4 /var/www/vilescrmoneboxc/web1/web/packages/SQLObject/SQLObject.class. php(1091): SQLObject->_makeQuery() #5 /var/www/vilescrmoneboxc/web1/web/api/db/Xplatform.class.php(364): SQLObject->getNext() #6 /var/www/ vilescrmoneboxc/web1/we b/api/services/SettingService.class.php(1183): Xplatform->getNext() #7 /var/www/vilescrmoneboxc/web1/web/ [Datei] => /var/www/vilescrmoneboxc/web1/web/ packages/ConnectionManager/ConnectionManager_MySQLi.class.php [line] => 44 ) Wollte man Daten aus der Konfiguration in der Konsole bekommen, war es ein langer Weg bis zur Datenbank. Kehren Sie freundlicherweise zu den Einzelhändlern der Website zurück. Garny Abend!

Hier ist das Systemprotokoll vom 2. Januar 22:25:01 viles systemd: Started Session 54934 von Benutzer root. ................................................. . ................2. Januar 22:30:11 viles journal: Laufzeitjournal verwendet 8,0 MB (maximal zulässige 91,5 MB, versucht, 137,2 MB frei von 907,0 MB verfügbar zu lassen → Strombegrenzung 91,5 M). 2. Januar 22:30:11 viles Kernel: Initialisierung cgroup Subsys cpuset 2. Januar 22:30:11 viles Kernel: Initialisierung cgroup Subsys cpu 2. Januar 22:30:11 viles Kernel: Initialisierung cgroup Subsys cpuacct 2. Januar 22:30:11 viles Kernel: Linux-Version 3.10.0-1127.10.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc-Version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)) #1 SMP Wed 3. Juni 1 4:28:03 UTC 2020 2. Januar 22:30:11 viles Kernel: Befehlszeile: root=UUID=0635e2fb-4091-41e2-9a10-5efef849183a ro crashkernel=auto rhgb quiet LANG=en_US.UTF-8 Jan 2 22:30:11 bösartiger Kernel: ACPI in unprivilegierter Domäne deaktiviert 2. Januar 22:30:11 bösartiger Kernel: e820: vom BIOS bereitgestellte physische RAM-Zuordnung: 2. Januar 22:30:11 bösartiger Kernel: Xen: [mem 0x0000000000000000-0x000000000009ffff ] nutzbar 2. Januar 22:30:11 viles Kernel: Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserviert 2. Januar 22:30:11 viles Kernel: Xen: [mem 0x0000000000100000-0x0000-0x0000:00007fffffff 2 Kernel: viles 2: viles 2 Kernel 2 NX (Execute Disable)-Schutz: aktiv 2. Januar 22:30:11 vi les Kernel: DMI nicht vorhanden oder ungültig. 2. Jan 22:30:11 viles kernel: e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000 2. Jan 22:30:11 viles kernel: RAMDISK: [mem 0x02c00000-0x03c40fff] 2. Jan 22:30:11 viles kernel: NUMA ausgeschaltet 2 22:30:11 viles Kernel: Fake a node at [mem 0x0000000000000000-0x000000007fffffff] 2. Jan 22:30:11 viles Kernel: NODE_DATA(0) zugewiesen [mem 0x7fc06000-0x7fc2cfff] 2. Jan 22:30:11 viles Kernel: Reservieren von 161 MB Speicher bei 720 MB für Crashkernel (System-RAM: 2047 MB) 11 viles Kernel: DMA32 [mem 0x01000000-0xffffffff] 2. Jan 22:30:11 viles Kernel: Normal leer 2. Jan 22:30:11 viles Kernel: Beweglicher Zonenstart für jeden Knoten 2. Jan 22:30:11 viles Kernel: Früh Speicherknotenbereiche 2. Januar 22:30:11 viles Kernel: Knoten 0: [mem 0x00001000-0x0009ffff] 2. Januar 22:30:11 viles Kernel: Knoten 0: [mem 0x00100000-0x7fffffff] ... 2. Januar 22:30: 17 viles kdumpctl: kexec: kdump Kernel 2. Januar 22:30:1 konnte nicht geladen werden 7 viles kdumpctl: Starten von kdump: [FEHLGESCHLAGEN] 2. Januar 22:30:17 viles systemd: Fehler beim Starten der Crash-Recovery-Kernel-Bewaffnung. 2. Jan 22:30:17 viles systemd: Startup beendet in 1.317s (Kernel) + 725ms (initrd) + 5.494s (Userspace) = 7.538s. 2. Januar 22:30:17 viles systemd: Unit kdump.service ist in den Fehlerzustand eingetreten. 2. Januar 22:30:17 viles systemd: kdump.service fehlgeschlagen. Und so bis heute. Und ja, der Hoster hat das Webserver-Log gelöscht.