Keyhelp-Webinterface und alle Webseiten immer kurz nach Neustart unzugänglich, Server nur noch über SSH zu erreichen!

[Manuel]

die Cron Jobs der User könnten hierbei eventl. auch eine Rolle spielen ... eventl. mal alle deaktivieren

Nein, geht nicht.
Cronjobs alle aus, alles nochmal aus dem Thread versucht.
Nichts geht.
Unter journalctl -f kommen auch nur noch sudo Anweisungen und solche AXFR/IN Sachen.

[Manuel]

PS: Wenn du mysqltuner über apt-get installiert hast, ruft du ihn einfach über den Befehl mysqltuner auf

Falls es wichtig ist, hab ich total vergessen, hier das Ergebnis vom mysqltuner Befehl:

Code: Select all

root@server ~ # mysqltuner
 >>  MySQLTuner 1.7.13 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[OK] Logged in using credentials from Debian maintenance account.
[OK] Currently running supported MySQL version 10.3.38-MariaDB-0ubuntu0.20.04.1-log
[OK] Operating on 64-bit architecture
 
-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: /var/log/mysql/error.log(91K)
[OK] Log file /var/log/mysql/error.log exists
[OK] Log file /var/log/mysql/error.log is readable.
[OK] Log file /var/log/mysql/error.log is not empty
[OK] Log file /var/log/mysql/error.log is smaller than 32 Mb
[!!] /var/log/mysql/error.log contains 9 warning(s).
[!!] /var/log/mysql/error.log contains 7 error(s).
[--] 32 start(s) detected in /var/log/mysql/error.log
[--] 1) 2023-08-04 18:41:09 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 2) 2023-08-04 18:40:03 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 3) 2023-08-04 18:19:03 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 4) 2023-08-04 18:10:57 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 5) 2023-08-04 17:46:28 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 6) 2023-08-04 17:25:01 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 7) 2023-08-04 17:09:13 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 8) 2023-08-04 16:46:54 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 9) 2023-08-04 16:16:35 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 10) 2023-08-04 16:14:49 0 [Note] /usr/sbin/mysqld: ready for connections.
[--] 32 shutdown(s) detected in /var/log/mysql/error.log
[--] 1) 2023-08-04 18:41:09 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 2) 2023-08-04 18:40:02 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 3) 2023-08-04 18:17:49 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 4) 2023-08-04 18:09:46 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 5) 2023-08-04 17:45:20 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 6) 2023-08-04 17:23:53 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 7) 2023-08-04 17:08:02 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 8) 2023-08-04 16:45:44 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 9) 2023-08-04 16:15:25 0 [Note] /usr/sbin/mysqld: Shutdown complete
[--] 10) 2023-08-04 16:14:49 0 [Note] /usr/sbin/mysqld: Shutdown complete
 
-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +Aria +CSV +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA +SEQUENCE 
[--] Data in MEMORY tables: 0B (Tables: 1)
[--] Data in InnoDB tables: 3.7G (Tables: 10488)
[--] Data in MyISAM tables: 34.3M (Tables: 1862)
[OK] Total fragmented tables: 0
[!!] Table '1zone_db5.currencies' has an autoincrement value near max capacity (100.00%)
 
-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.
 
-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] User 'develope_account_namegeandert_db1@%' does not specify hostname restrictions.
[--] There are 618 basic passwords in the list.
 
-------- CVE Security Recommendations --------------------------------------------------------------
[OK] NO SECURITY CVE FOUND FOR YOUR VERSION
 
-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 10m 46s (9K q [14.873 qps], 2K conn, TX: 5M, RX: 1M)
[--] Reads / Writes: 99% / 1%
[--] Binary logging is disabled
[--] Physical Memory     : 31.3G
[--] Max MySQL memory    : 2.1G
[--] Other process memory: 2.3G
[--] Total buffers: 1.5G global + 2.9M per thread (200 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 1.5G (4.86% of installed RAM)
[OK] Maximum possible memory usage: 2.1G (6.62% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/9K)
[OK] Highest usage of available connections: 2% (4/200)
[OK] Aborted connections: 0.00%  (0/2991)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[!!] Query cache may be disabled by default due to mutex contention.
[OK] Query cache efficiency: 37.0% (3K cached / 10K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 4 sorts)
[OK] No joins without indexes
[OK] Temporary tables created on disk: 2% (6 on disk / 218 total)
[OK] Thread cache hit rate: 99% (4 created / 2K connections)
[!!] Table cache hit rate: 14% (8K open / 56K opened)
[OK] Open file limit used: 3% (2K/80K)
[OK] Table locks acquired immediately: 100% (2K immediate / 2K locks)
 
-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is disabled.
[--] Memory used by P_S: 0B
[--] Sys schema isn't installed.
 
-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 8 thread(s).
[--] Using default value is good enough for your version (10.3.38-MariaDB-0ubuntu0.20.04.1-log)
 
-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.3% (47M used / 262M cache)
[OK] Key buffer size / total MyISAM indexes: 250.0M/12.7M
[!!] Read Key buffer hit rate: 83.6% (110 cached / 18 reads)
 
-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[!!] InnoDB buffer pool / data size: 512.0M/3.7G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (18.75 %): 48.0M * 2/512.0M should be equal 25%
[OK] InnoDB buffer pool instances: 1
[--] Number of InnoDB Buffer Pool Chunk : 4 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 92.99% (508958 hits/ 547301 total)
[!!] InnoDB Write Log efficiency: 514.29% (36 hits/ 7 total)
[OK] InnoDB log waits: 0.00% (0 waits / 43 writes)
 
-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is enabled.
[OK] Aria pagecache size / total Aria indexes: 128.0M/1B
[OK] Aria pagecache hit rate: 100.0% (62K cached / 6 reads)
 
-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.
 
-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.
 
-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.
 
-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: MIXED
[--] XA support enabled: ON
[--] Semi synchronous replication Master: OFF
[--] Semi synchronous replication Slave: OFF
[--] This is a standalone server
 
-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Control warning line(s) into /var/log/mysql/error.log file
    Control error line(s) into /var/log/mysql/error.log file
    Restrict Host for user@% to user@SpecificDNSorIp
    MySQL was started within the last 24 hours - recommendations may be inaccurate
    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
    Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optimizing-table_open_cache/
    This is MyISAM only table_cache scalability problem, InnoDB not affected.
    See more details here: https://bugs.mysql.com/bug.php?id=49177
    This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
    Beware that open_files_limit (80000) variable 
    should be greater than table_open_cache (8192)
    Performance schema should be activated for better diagnostics
    Consider installing Sys schema from https://github.com/mysql/mysql-sys
    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU
Variables to adjust:
    query_cache_size (=0)
    query_cache_type (=0)
    table_open_cache (> 8192)
    performance_schema = ON enable PFS
    innodb_buffer_pool_size (>= 3.7G) if possible.
    innodb_log_file_size should be (=64M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
root@server ~ # 

[Florian]

Wie gesagt: Wenn das Problem auftritt schau mittels dmesg ob da Probleme geloggt werden und schau auch in /var/log/apache2/error.log ob z.B. die Grenze für MaxRequestWorkers erreicht wurde

[Ralph]

die Cron Jobs der User könnten hierbei eventl. auch eine Rolle spielen ... eventl. mal alle deaktivieren

Nein, geht nicht.
Cronjobs alle aus, alles nochmal aus dem Thread versucht.
Nichts geht.
Unter journalctl -f kommen auch nur noch sudo Anweisungen und solche AXFR/IN Sachen.

Nach jeder Änderung müssen die entsprechenden Dienste neu gestartet werden, nach stoppen der User Cron Jobs z.b. Apache, PHP, Mysql neu starten und die Logs danach im Auge behalten. Die User Cronjobs alle während der Überprüfung deaktivieren, nicht nur kurz aus und wieder an.

Vorrausgesetzt die OpenFile Limits wurden bereits höher gesetzt und greifen, die Ausgabe von mysqltuner bitte auch lesen und die Empfehlungen in der Mysql config setzen.

Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optim ... pen_cache/

die Mysql Prozesse auch mal prüfen welche User da im Spiel sind:

Code: Select all

mysqladmin processlist

[Manuel]

Wie gesagt: Wenn das Problem auftritt schau mittels dmesg ob da Probleme geloggt werden und schau auch in /var/log/apache2/error.log ob z.B. die Grenze für MaxRequestWorkers erreicht wurde

Hallo Florian,
Hab mich mal ein wenig eingelesen, scheint das es der Apache2 Webservers ist, Sobald ich den Befehl für Neustart ausführe geht wieder alles.

Apache2 Webservers Neustart:

Code: Select all

sudo service apache2 restart

Ich habe nun mal in der Datei /etc/apache2/mods-enabled.mpm_worker.conf einstellungen geändert und zwar wie folgt:

Original Werte:

Code: Select all

# worker MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadLimit: ThreadsPerChild can be changed to this maximum value during a
#			  graceful restart. ThreadLimit can only be changed by stopping
#			  and starting Apache.
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of threads
# MaxConnectionsPerChild: maximum number of requests a server process serves

<IfModule mpm_worker_module>
	StartServers			 2
	MinSpareThreads		 25
	MaxSpareThreads		 75
	ThreadLimit			 64
	ThreadsPerChild		 25
	MaxRequestWorkers	  150
	MaxConnectionsPerChild   0
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

NEUE Werte:

Code: Select all

# worker MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadLimit: ThreadsPerChild can be changed to this maximum value during a
#			  graceful restart. ThreadLimit can only be changed by stopping
#			  and starting Apache.
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of threads
# MaxConnectionsPerChild: maximum number of requests a server process serves

<IfModule mpm_worker_module>
	StartServers			 2
	MinSpareThreads		 25
	MaxSpareThreads		 75
	ThreadLimit			 64
	ThreadsPerChild		 25
	MaxRequestWorkers	  300
	MaxConnectionsPerChild   0
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Ich beobachte das mal.
Warum das plötzlich gekommen ist kann ich nicht sagen, wie gesagt, der server ist eigentlich nur am laufen und das wars.
Nix neues etc.

[24unix]

Ich wundere mich, dass bei Dir mpm_worker aktiv ist.

IMHP ist seit ner Weile mpm_event Standard unter KH.

[Manuel]

die Cron Jobs der User könnten hierbei eventl. auch eine Rolle spielen ... eventl. mal alle deaktivieren

Nein, geht nicht.
Cronjobs alle aus, alles nochmal aus dem Thread versucht.
Nichts geht.
Unter journalctl -f kommen auch nur noch sudo Anweisungen und solche AXFR/IN Sachen.

Nach jeder Änderung müssen die entsprechenden Dienste neu gestartet werden, nach stoppen der User Cron Jobs z.b. Apache, PHP, Mysql neu starten und die Logs danach im Auge behalten. Die User Cronjobs alle während der Überprüfung deaktivieren, nicht nur kurz aus und wieder an.

Vorrausgesetzt die OpenFile Limits wurden bereits höher gesetzt und greifen, die Ausgabe von mysqltuner bitte auch lesen und die Empfehlungen in der Mysql config setzen.

Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optim ... pen_cache/

die Mysql Prozesse auch mal prüfen welche User da im Spiel sind:

Code: Select all

mysqladmin processlist

Hy Danke, habs mir kurz angesehen. Muss ich mir genauer durchlesen.

Das kommt beim Befehl raus:

Code: Select all

root@server ~ # mysqladmin processlist
+-------+-------------+-----------------+---------+---------+-------+--------------------------+------------------+----------+
| Id    | User        | Host            | db      | Command | Time  | State                    | Info             | Progress |
+-------+-------------+-----------------+---------+---------+-------+--------------------------+------------------+----------+
| 1     | system user |                 |         | Daemon  |       | InnoDB purge coordinator |                  | 0.000    |
| 2     | system user |                 |         | Daemon  |       | InnoDB purge worker      |                  | 0.000    |
| 3     | system user |                 |         | Daemon  |       | InnoDB purge worker      |                  | 0.000    |
| 4     | system user |                 |         | Daemon  |       | InnoDB purge worker      |                  | 0.000    |
| 5     | system user |                 |         | Daemon  |       | InnoDB shutdown handler  |                  | 0.000    |
| 1977  | keyhelp     | localhost:50020 | keyhelp | Sleep   | 5952  |                          |                  | 0.000    |
| 4062  | keyhelp     | localhost:44556 | keyhelp | Sleep   | 19002 |                          |                  | 0.000    |
| 11512 | keyhelp     | localhost       | keyhelp | Sleep   | 30    |                          |                  | 0.000    |
| 11528 | root        | localhost       |         | Query   | 0     | Init                     | show processlist | 0.000    |
+-------+-------------+-----------------+---------+---------+-------+--------------------------+------------------+----------+
root@server ~ # 

Der server ist schon wieder unerreichbar gewesen, habe vorerst nichts geändert aber den Apache-Server neu gestartet mit dem Befehl

Code: Select all

sudo service apache2 restart

Nach der Eingabe des Befehls funktioniert eine Zeit lang alles wieder normal, dann muss der Server irgendwann neu gestartet werden.
Wie gesagt, ich bin kein Profi und es ist gibt auch aktuell niemanden im Umkreis, der sich mit Linux auskennt.
Der ganze produktive Kram läuft bereits auf einem anderen Server, aber dieser Server sollte auch wieder funktionieren.
Was ich sagen will, ich denke, es kann am Server liegen, denn das ist bisher das einzige, was reproduzierbare Besserung bewirkt.
Danke an alle für die Zeit wird ein langes WOE

[Manuel]

Ich wundere mich, dass bei Dir mpm_worker aktiv ist.

IMHP ist seit ner Weile mpm_event Standard unter KH.

das mpm_event habe ich auch gesucht, hab ich aber nicht am server, dann bin ich auf einen thread aus 2020 hier gestossen und versuche mal einzeln die einstellungen zu übernehmen. Funktioniert hat es noch nicht, der Apache muss ständig neu gestartet werden.

Ich überlege gerade das mit einem Cronjob alle 5 Minuten erstmal lösen bis ich einen neuen Admin finde.

UPDATE:
mpm_event.conf habe ich nun hier gefunden: /etc/apache2/mods-available
mpm_worker.conf war hier: /etc/apache2/mods-enabled

Hab mal bei der mpm_event.conf auch mal MaxRequestWorker angehoben von 150 zu 300.
Mal sehen.


Ausserdem hab ich nochmal mysqladmin processlist laufen lassen mit folgendem Ergebnis nach dem reboot:

Code: Select all

root@server ~ # mysqladmin processlist
+----+-------------+-----------+---------+---------+------+--------------------------+------------------------------------------------------------------------------------------------------+----------+
| Id | User        | Host      | db      | Command | Time | State                    | Info                                                                                                 | Progress |
+----+-------------+-----------+---------+---------+------+--------------------------+------------------------------------------------------------------------------------------------------+----------+
| 1  | system user |           |         | Daemon  |      | InnoDB purge coordinator |                                                                                                      | 0.000    |
| 2  | system user |           |         | Daemon  |      | InnoDB purge worker      |                                                                                                      | 0.000    |
| 3  | system user |           |         | Daemon  |      | InnoDB purge worker      |                                                                                                      | 0.000    |
| 4  | system user |           |         | Daemon  |      | InnoDB purge worker      |                                                                                                      | 0.000    |
| 5  | system user |           |         | Daemon  |      | InnoDB shutdown handler  |                                                                                                      | 0.000    |
| 10 | root        | localhost |         | Query   | 3    | Checking permissions     | select concat('select count(*) into @discard from `',
                    TABLE_SCHEMA, '`.`', TABLE | 0.000    |
| 11 | keyhelp     | localhost | keyhelp | Sleep   | 2    |                          |                                                                                                      | 0.000    |
| 12 | root        | localhost |         | Query   | 0    | Init                     | show processlist                                                                                     | 0.000    |
+----+-------------+-----------+---------+---------+------+--------------------------+------------------------------------------------------------------------------------------------------+----------+
root@server ~ # 

[Ralph]

Kannst du bitte für folgendes die outputs posten?

Code: Select all

ls /home/users/*/tmp/* | wc -l

---
ulimit -Hn

---
ulimit -Sn

---
ulimit -a

---
grep -r "open_files_limit" /etc

---
mysql
show variables like "open_files%";
exit

[Manuel]

Natürlich, hier.
Bei zwei passiert aber nix.

Kannst du bitte für folgendes die outputs posten?

Code: Select all

ls /home/users/*/tmp/* | wc -l
HÄNGT, KOMMT NIX
---
ulimit -Hn
200000
---
ulimit -Sn
200000
---
ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 127868
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 200000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127868
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
---
grep -r "open_files_limit" /etc
HÄNGT, KOMMT NIX
---
mysql
show variables like "open_files%";
exit

root@server ~ # mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 1960
Server version: 10.3.38-MariaDB-0ubuntu0.20.04.1-log Ubuntu 20.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show variables like "open_files%";
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| open_files_limit | 131311 |
+------------------+--------+
1 row in set (0.001 sec)

MariaDB [(none)]> exit
Bye

Aktuell läuft er noch nach dem reboot und Anpassung der mpm_event.conf

[Jolinar]

Der einfachste und sicherste Weg, die Kiste wieder fehlerfrei zum Laufen zu bekommen:

Vollständiges Backup aller Userdaten anlegen, Kiste komplett neu aufsetzen, Backup wieder einspielen, glücklich sein

[Ralph]

ls /home/users/*/tmp/* | wc -l
HÄNGT, KOMMT NIX

Dann prüfe mal die /tmp Folder der User, da sind dann irgendwo vermutlich unzählige tmp files vorhanden.
Das könnte duch eine Attacke (Sicherheitslücke) verursacht werden oder eben durch einen oder mehrere von den User Cron Jobs.
### edit ###
kannst auch noch die Speicherplatz Belegung der /tmp Folder prüfen z.b.

Code: Select all

du -sh /home/users/*/tmp/ | sort -n -r

[24unix]

Der einfachste und sicherste Weg, die Kiste wieder fehlerfrei zum Laufen zu bekommen:

Vollständiges Backup aller Userdaten anlegen, Kiste komplett neu aufsetzen, Backup wieder einspielen, glücklich sein

Das wäre mein Ansatz, wenn es zeitkritisch wäre, aber eigentlich will man doch wissen, wo es klemmt.

Einfach neu aufsetzten kenne ich von anderen Systemen

[Manuel]

ls /home/users/*/tmp/* | wc -l
HÄNGT, KOMMT NIX

Dann prüfe mal die /tmp Folder der User, da sind dann irgendwo vermutlich unzählige tmp files vorhanden.
Das könnte duch eine Attacke (Sicherheitslücke) verursacht werden oder eben durch einen oder mehrere von den User Cron Jobs.

Ok, nun ist er fertig geworden:

grep -r "open_files_limit" /etc
/etc/mysql/mariadb.conf.d/90-tuning.cnf:open_files_limit = 16544

---------------------
ls /home/users/*/tmp/* | wc -l
-bash: /bin/ls: Argument list too long
0

Ich schau gleich in den tmp Ordnern nach.
Kann man die auch einfach bereinigen?

[Ralph]

Der einfachste und sicherste Weg, die Kiste wieder fehlerfrei zum Laufen zu bekommen:

Vollständiges Backup aller Userdaten anlegen, Kiste komplett neu aufsetzen, Backup wieder einspielen, glücklich sein

Das wäre mein Ansatz, wenn es zeitkritisch wäre, aber eigentlich will man doch wissen, wo es klemmt.

Einfach neu aufsetzten kenne ich von anderen Systemen

sieht eher nach einem Problem durch Anwender Software in den Webs aus, also wird das Problem vermutlich auch nach einer Neu Installation wieder auftauchen