Job for mariadb.service failed ....

oemi

New Member
Hallo,

irgendwie will die Datenbank unter Plesk nicht starten und es kommt folgende Meldung:

Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

Status zeigt folgendes an:
Code:
mariadb.service - MariaDB 10.1.38 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-07-22 15:49:06 CEST; 2min 46s ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 1502 ExecStartPost=/etc/mysql/debian-start (code=exited, status=226/NAMESPACE)
  Process: 4958 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=killed, signal=ABRT)
  Process: 4874 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 4862 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 6493 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=226/NAMESPACE)
Main PID: 4958 (code=killed, signal=ABRT)
      CPU: 2ms

Jul 22 15:49:06 v22019078721xxxxx systemd[1]: Starting MariaDB 10.1.38 database server...
Jul 22 15:49:06 v22019078721xxxxx systemd[1]: mariadb.service: Control process exited, code=exited status=226
Jul 22 15:49:06 v22019078721xxxxx systemd[1]: Failed to start MariaDB 10.1.38 database server.
Jul 22 15:49:06 v22019078721xxxxx systemd[1]: mariadb.service: Unit entered failed state.
Jul 22 15:49:06 v22019078721xxxxx systemd[1]: mariadb.service: Failed with result 'exit-code'
Hat einer Rat?
 
Last edited by a moderator:

mr_brain

Registered User
Was sagen die Logs dazu?

Mal mariaDB einfach so gestartet und geschaut, was es für Fehlermeldungen auswirft?
 

oemi

New Member
root@v22019078721xxxxxx:~# systemctl start mysql
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
 

mr_brain

Registered User
Direkt das mariaDB starten und nicht via den Skripten.

Des weiteren schauen was im Log /var/log/mariadb/mariadb.log steht.
 

oemi

New Member
Ich hoffe du meinst, dass ich es so machen soll:
root@v2201907872xxxxxx:~# service mariadb start
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

hier der Log
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: The InnoDB memory heap is disabled
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: Using Linux native AIO
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: Using SSE crc32 instructions
2019-07-22 14:23:50 140545157229952 [ERROR] mysqld: Can't create/write to file '/tmp/ibWVoFiv' (Errcode: 28 "No space left on device")
2019-07-22 14:23:50 140545157229952 [Warning] InnoDB: Unable to create temp file to check native AIO support.
2019-07-22 14:23:50 140545157229952 [Warning] InnoDB: Linux Native AIO disabled.
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-07-22 14:23:50 140545157229952 [Note] InnoDB: Completed initialization of buffer pool
2019-07-22 14:23:50 140545157229952 [ERROR] mysqld: Can't create/write to file '/tmp/ib6Jhet2' (Errcode: 28 "No space left on device")
2019-07-22 14:23:50 7fd3382bed80 InnoDB: Error: unable to create temporary file; errno: 28
2019-07-22 14:23:50 7fd3382bed80 InnoDB: Assertion failure in thread 140545157229952 in file lock0lock.cc line 668
InnoDB: Failing assertion: lock_latest_err_file
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
190722 14:23:50 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.38-MariaDB-0+deb9u1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352467 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x5593506d974e]
/usr/sbin/mysqld(handle_fatal_signal+0x3bd)[0x55935021a5ad]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7fd337f2a0e0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fd336a97fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fd336a9942a]
/usr/sbin/mysqld(+0x85bd40)[0x5593504d0d40]
/usr/sbin/mysqld(+0x912b46)[0x559350587b46]
/usr/sbin/mysqld(+0x827821)[0x55935049c821]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x62)[0x55935021c6f2]
/usr/sbin/mysqld(+0x421a25)[0x559350096a25]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x7da)[0x55935009806a]
/usr/sbin/mysqld(+0x37a0ec)[0x55934ffef0ec]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1b7e)[0x55934fff2bae]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fd336a852e1]
/usr/sbin/mysqld(_start+0x2a)[0x55934ffe6dba]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
 

oemi

New Member
Darf man den Inhalt des tmp Ordners einfach so löschen oder kann dies zu Problemen führen?
 

mr_brain

Registered User
Innert /tmp kannst du problemlos löschen.

"No space left on device" heisst im übrigen, dass die Partition voll ist. Da muss ja nicht unbedingt /tmp dran Schuld sein. Muss man halt schauen, wie die Partitionen sind und wie voll die jeweiligen Verzeichnisse sind.
 

oemi

New Member
Habe leider so gut wie keinen Plan!
kannst du mir sagen wie ich checken kann ob die Partitionen voll sind?
 

oemi

New Member
root@v2201907872xxxxxx:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.9G 0 7.9G 0% /dev
tmpfs 1.6G 11M 1.6G 1% /run
/dev/sda3 157G 48G 103G 32% /
tmpfs 7.9G 0 7.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/sda2 976M 37M 873M 4% /boot
tmpfs 1.6G 0 1.6G 0% /run/user/0
 

oemi

New Member
Falls es jemanden gib, der das Problem gegen Zahlung löst, bitte ich mit einem Angebot um eine PM.
 

PHP-Friends

Blog Benutzer
Wie vermutet waren hier die Inodes voll. Schuld war ein vollgelaufenes Cache-Verzeichnis eines Shopsystems. Für die Zukunft empfehle ich ein entsprechendes Monitoring :)

Viele Grüße
Tim
 

oemi

New Member
Es handelt sich um einen Bug des jtl shop, wenn man caching mehrsprachig aktiviert, läuft dieser voll.
hast du mir die Rechnung geschickt?
 

mr_brain

Registered User
Im JTL kann man doch auch das Cache auf die Datenbank einstellen und zudem noch das den Zeitraum für die gecachten Daten definieren.
 

Top