Hello all, after the last upgrade, if i run
diepi-services status
everuthing is ok, but i get back the error in the title.
Someone knows how to solve this situation?
Thanks for the support!
Hi,
can you share some more information. Where do you have this error message? On wich application?
I’m getting the error via browser and also via the PC( Windows ) application
Thx for the support, if you need further infos, let me know!
still, what are you trying to do? What application you are trying to access?
I’m trying to access OwnCloud, sorry i’ve forgot that little detail 
Everything was working properly before the updates…
are you able to reach your web server directly just using the IP address? let’s check as well LISTEN ports on your system
ss -tulpn | grep LISTEN
Hello Joulinar this is what i’ve get:
tcp LISTEN 0 511 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=511,fd=7))
tcp LISTEN 0 1024 0.0.0.0:80 0.0.0.0:* users:(("lighttpd",pid=668,fd=4))
tcp LISTEN 0 1000 0.0.0.0:22 0.0.0.0:* users:(("dropbear",pid=487,fd=3))
tcp LISTEN 0 511 [::1]:6379 [::]:* users:(("redis-server",pid=511,fd=8))
tcp LISTEN 0 1024 [::]:80 [::]:* users:(("lighttpd",pid=668,fd=5))
tcp LISTEN 0 1000 [::]:22 [::]:* users:(("dropbear",pid=487,fd=4))
Any ideas?
ok lighttpd web server seems to be running. What happen of you just try to access the server by http://192.168.x.x ? Does it give anything? As well pls can you share web server document root ls -la /var/www/
As well I’m missing the data base process on your output. pls can you share systemctl status mariadb.service
Actually i’m connected via noip and talking on the 22 port, so i think everything is ok.
Also locally if i try to connect directly with the IP address so 192.168.x.x/owncloud i’m getting the same error.
This is what i’m getting:
root@DietPi:~# ls -la /var/www/
total 84
drwxr-xr-x 3 root root 4096 Feb 19 10:44 .
drwxr-xr-x 12 root root 4096 Dec 18 20:38 ..
-rw-r--r-- 1 root root 37984 Dec 18 20:52 apc.php
-rw-r--r-- 1 root root 216 Jan 11 10:04 index.lighttpd.html
-rw-r--r-- 1 root root 22915 Dec 18 20:52 opcache.php
drwxr-xr-x 13 www-data www-data 4096 Feb 19 10:46 owncloud
-rw-r--r-- 1 root root 20 Dec 18 20:52 phpinfo.php
you are trying to connect from internet or from local network? And I ask to use 192.168.x.x only without onwcloud subfolder. As well pls share status of your database because it’s missing within process overview and it doesn’t seems to be LISTEN
Hello Joulinar,
sorry for the daly in my reply.
I’ve checked the status
dietpi-services status
, and this is what i get:
[ OK ] DietPi-Services | redis-server active (running) since Fri 2021-02-19 10:54:40 GMT; 2 days ago
[ OK ] DietPi-Services | mariadb activating (auto-restart) (Result: signal) since Mon 2021-02-22 07:48:34 GMT; 4s ago
[ OK ] DietPi-Services | php7.3-fpm active (running) since Fri 2021-02-19 10:54:45 GMT; 2 days ago
[ OK ] DietPi-Services | lighttpd active (running) since Fri 2021-02-19 10:54:46 GMT; 2 days ago
[ OK ] DietPi-Services | cron active (running) since Fri 2021-02-19 10:54:46 GMT; 2 days ago
[ OK ] DietPi-Services | dropbear active (running) since Fri 2021-02-19 10:54:40 GMT; 2 days ago
[ OK ] DietPi-Services | fail2ban active (running) since Fri 2021-02-19 10:53:47 GMT; 2 days ago
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Fri 2021-02-19 10:53:46 GMT; 2 days ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Fri 2021-02-19 10:53:47 GMT; 2 days ago
[ OK ] DietPi-Services | dietpi-boot active (exited) since Fri 2021-02-19 10:54:39 GMT; 2 days ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Fri 2021-02-19 10:54:39 GMT; 2 days ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
there you go, your MariaDB is not in active status. Therefore Owncloud is not able to connect and run. Pls share following
systemctl restart mariadb.service
journalctl -u mariadb
cat /var/log/mysql/error.log
readlink /var/lib/mysql
readlink -f /var/lib/mysql
Here you have!
root@DietPi:~# systemctl restart mariadb.service
Job for mariadb.service failed because a fatal signal was delivered to the control process.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
root@DietPi:~# journalctl -u mariadb
-- Logs begin at Mon 2021-02-22 08:27:58 GMT, end at Mon 2021-02-22 10:21:34 GMT. --
Feb 22 08:27:58 DietPi mysqld[7726]: or one of the libraries it was linked against is corrupt, improperly built,
Feb 22 08:27:58 DietPi mysqld[7726]: or misconfigured. This error can also be caused by malfunctioning hardware.
Feb 22 08:27:58 DietPi mysqld[7726]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Feb 22 08:27:58 DietPi mysqld[7726]: We will try our best to scrape up some info that will hopefully help
Feb 22 08:27:58 DietPi mysqld[7726]: diagnose the problem, but since we have already crashed,
Feb 22 08:27:58 DietPi mysqld[7726]: something is definitely wrong and this may fail.
Feb 22 08:27:58 DietPi mysqld[7726]: Server version: 10.3.27-MariaDB-0+deb10u1
Feb 22 08:27:58 DietPi mysqld[7726]: key_buffer_size=134217728
Feb 22 08:27:58 DietPi mysqld[7726]: read_buffer_size=131072
Feb 22 08:27:58 DietPi mysqld[7726]: max_used_connections=0
Feb 22 08:27:58 DietPi mysqld[7726]: max_threads=153
Feb 22 08:27:58 DietPi mysqld[7726]: thread_count=0
Feb 22 08:27:58 DietPi mysqld[7726]: It is possible that mysqld could use up to
Feb 22 08:27:58 DietPi mysqld[7726]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466214 K bytes of memory
Feb 22 08:27:58 DietPi mysqld[7726]: Hope that's ok; if not, decrease some variables in the equation.
Feb 22 08:27:58 DietPi mysqld[7726]: Thread pointer: 0x0
Feb 22 08:27:58 DietPi mysqld[7726]: Attempting backtrace. You can use the following information to find out
Feb 22 08:27:58 DietPi mysqld[7726]: where mysqld died. If you see no messages after this, something went
Feb 22 08:27:58 DietPi mysqld[7726]: terribly wrong...
Feb 22 08:27:58 DietPi mysqld[7726]: stack_bottom = 0x0 thread_stack 0x49000
Feb 22 08:27:58 DietPi mysqld[7726]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
Feb 22 08:27:58 DietPi mysqld[7726]: information that should help you find out what is causing the crash.
Feb 22 08:27:58 DietPi mysqld[7726]: Writing a core file...
Feb 22 08:27:58 DietPi mysqld[7726]: Working directory at /mnt/HD1T/dietpi_userdata/mysql
Feb 22 08:27:58 DietPi mysqld[7726]: Resource Limits:
Feb 22 08:27:58 DietPi mysqld[7726]: Fatal signal 11 while backtracing
Feb 22 08:27:58 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=11/SEGV
Feb 22 08:27:58 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Feb 22 08:27:58 DietPi systemd[1]: Failed to start MariaDB 10.3.27 database server.
Feb 22 08:28:03 DietPi systemd[1]: mariadb.service: Service RestartSec=5s expired, scheduling restart.
Feb 22 08:28:03 DietPi systemd[1]: mariadb.service: Scheduled restart job, restart counter is at 40226.
Feb 22 08:28:03 DietPi systemd[1]: Stopped MariaDB 10.3.27 database server.
Feb 22 08:28:03 DietPi systemd[1]: Starting MariaDB 10.3.27 database server...
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Note] /usr/sbin/mysqld (mysqld 10.3.27-MariaDB-0+deb10u1) starting as process 7801 ...
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Warning] Could not increase number of max_open_files to more than 16384 (request: 32186)
Feb 22 08:28:03 DietPi mysqld[7801]: /usr/sbin/mysqld: Can't create file '/var/log/mysql/error.log' (errno: 2 "No such file or directory")
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Note] InnoDB: Using Linux native AIO
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Note] InnoDB: Uses event mutexes
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Note] InnoDB: Number of pools: 1
Feb 22 08:28:03 DietPi mysqld[7801]: 2021-02-22 8:28:03 0 [Note] InnoDB: Using generic crc32 instructions
Feb 22 08:28:04 DietPi mysqld[7801]: 2021-02-22 8:28:04 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
Feb 22 08:28:04 DietPi mysqld[7801]: 2021-02-22 8:28:04 0 [Note] InnoDB: Completed initialization of buffer pool
Feb 22 08:28:04 DietPi mysqld[7801]: 2021-02-22 8:28:04 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
Feb 22 08:28:04 DietPi mysqld[7801]: 2021-02-22 8:28:04 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=265033300
Feb 22 08:28:04 DietPi mysqld[7801]: 2021-02-22 8:28:04 0 [Note] InnoDB: Starting final batch to recover 1 pages from redo log.
Feb 22 08:28:04 DietPi mysqld[7801]: 2021-02-22 08:28:04 0x579013e0 InnoDB: Assertion failure in file /build/mariadb-10.3-S9bYSW/mariadb-10.3-10.3.27/storage/innobase/rem/rem0rec.cc line 815
Feb 22 08:28:04 DietPi mysqld[7801]: InnoDB: We intentionally generate a memory trap.
Feb 22 08:28:04 DietPi mysqld[7801]: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
Feb 22 08:28:04 DietPi mysqld[7801]: InnoDB: If you get repeated assertion failures or crashes, even
Feb 22 08:28:04 DietPi mysqld[7801]: InnoDB: immediately after the mysqld startup, there may be
Feb 22 08:28:04 DietPi mysqld[7801]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Feb 22 08:28:04 DietPi mysqld[7801]: InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
Feb 22 08:28:04 DietPi mysqld[7801]: InnoDB: about forcing recovery.
Feb 22 08:28:04 DietPi mysqld[7801]: 210222 8:28:04 [ERROR] mysqld got signal 6 ;
Feb 22 08:28:04 DietPi mysqld[7801]: This could be because you hit a bug. It is also possible that this binary
Feb 22 08:28:04 DietPi mysqld[7801]: or one of the libraries it was linked against is corrupt, improperly built,
Feb 22 08:28:04 DietPi mysqld[7801]: or misconfigured. This error can also be caused by malfunctioning hardware.
Feb 22 08:28:04 DietPi mysqld[7801]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Feb 22 08:28:04 DietPi mysqld[7801]: We will try our best to scrape up some info that will hopefully help
Feb 22 08:28:04 DietPi mysqld[7801]: diagnose the problem, but since we have already crashed,
Feb 22 08:28:04 DietPi mysqld[7801]: something is definitely wrong and this may fail.
Feb 22 08:28:04 DietPi mysqld[7801]: Server version: 10.3.27-MariaDB-0+deb10u1
Feb 22 08:28:04 DietPi mysqld[7801]: key_buffer_size=134217728
Feb 22 08:28:04 DietPi mysqld[7801]: read_buffer_size=131072
Feb 22 08:28:04 DietPi mysqld[7801]: max_used_connections=0
Feb 22 08:28:04 DietPi mysqld[7801]: max_threads=153
Feb 22 08:28:04 DietPi mysqld[7801]: thread_count=0
Feb 22 08:28:04 DietPi mysqld[7801]: It is possible that mysqld could use up to
Feb 22 08:28:04 DietPi mysqld[7801]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466214 K bytes of memory
Feb 22 08:28:04 DietPi mysqld[7801]: Hope that's ok; if not, decrease some variables in the equation.
Feb 22 08:28:04 DietPi mysqld[7801]: Thread pointer: 0x0
Feb 22 08:28:04 DietPi mysqld[7801]: Attempting backtrace. You can use the following information to find out
Feb 22 08:28:04 DietPi mysqld[7801]: where mysqld died. If you see no messages after this, something went
Feb 22 08:28:04 DietPi mysqld[7801]: terribly wrong...
Feb 22 08:28:04 DietPi mysqld[7801]: stack_bottom = 0x0 thread_stack 0x49000
Feb 22 08:28:04 DietPi mysqld[7801]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
Feb 22 08:28:04 DietPi mysqld[7801]: information that should help you find out what is causing the crash.
Feb 22 08:28:04 DietPi mysqld[7801]: Writing a core file...
Feb 22 08:28:04 DietPi mysqld[7801]: Working directory at /mnt/HD1T/dietpi_userdata/mysql
Feb 22 08:28:04 DietPi mysqld[7801]: Resource Limits:
Feb 22 08:28:04 DietPi mysqld[7801]: Fatal signal 11 while backtracing
Feb 22 08:28:04 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=11/SEGV
Feb 22 08:28:04 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Feb 22 08:28:04 DietPi systemd[1]: Failed to start MariaDB 10.3.27 database server.
Feb 22 08:28:09 DietPi systemd[1]: mariadb.service: Service RestartSec=5s expired, scheduling restart.
Feb 22 08:28:09 DietPi systemd[1]: mariadb.service: Scheduled restart job, restart counter is at 40227.
Feb 22 08:28:09 DietPi systemd[1]: Stopped MariaDB 10.3.27 database server.
Feb 22 08:28:09 DietPi systemd[1]: Starting MariaDB 10.3.27 database server...
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] /usr/sbin/mysqld (mysqld 10.3.27-MariaDB-0+deb10u1) starting as process 7875 ...
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Warning] Could not increase number of max_open_files to more than 16384 (request: 32186)
Feb 22 08:28:10 DietPi mysqld[7875]: /usr/sbin/mysqld: Can't create file '/var/log/mysql/error.log' (errno: 2 "No such file or directory")
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Using Linux native AIO
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Uses event mutexes
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Number of pools: 1
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Using generic crc32 instructions
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Completed initialization of buffer pool
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=265033300
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 8:28:10 0 [Note] InnoDB: Starting final batch to recover 1 pages from redo log.
Feb 22 08:28:10 DietPi mysqld[7875]: 2021-02-22 08:28:10 0x578933e0 InnoDB: Assertion failure in file /build/mariadb-10.3-S9bYSW/mariadb-10.3-10.3.27/storage/innobase/rem/rem0rec.cc line 815
Feb 22 08:28:10 DietPi mysqld[7875]: InnoDB: We intentionally generate a memory trap.
Feb 22 08:28:10 DietPi mysqld[7875]: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
Feb 22 08:28:10 DietPi mysqld[7875]: InnoDB: If you get repeated assertion failures or crashes, even
Feb 22 08:28:10 DietPi mysqld[7875]: InnoDB: immediately after the mysqld startup, there may be
Feb 22 08:28:10 DietPi mysqld[7875]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Feb 22 08:28:10 DietPi mysqld[7875]: InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
Feb 22 08:28:10 DietPi mysqld[7875]: InnoDB: about forcing recovery.
Feb 22 08:28:10 DietPi mysqld[7875]: 210222 8:28:10 [ERROR] mysqld got signal 6 ;
Feb 22 08:28:10 DietPi mysqld[7875]: This could be because you hit a bug. It is also possible that this binary
Feb 22 08:28:10 DietPi mysqld[7875]: or one of the libraries it was linked against is corrupt, improperly built,
Feb 22 08:28:10 DietPi mysqld[7875]: or misconfigured. This error can also be caused by malfunctioning hardware.
Feb 22 08:28:10 DietPi mysqld[7875]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Feb 22 08:28:10 DietPi mysqld[7875]: We will try our best to scrape up some info that will hopefully help
Feb 22 08:28:10 DietPi mysqld[7875]: diagnose the problem, but since we have already crashed,
Feb 22 08:28:10 DietPi mysqld[7875]: something is definitely wrong and this may fail.
Feb 22 08:28:10 DietPi mysqld[7875]: Server version: 10.3.27-MariaDB-0+deb10u1
Feb 22 08:28:10 DietPi mysqld[7875]: key_buffer_size=134217728
Feb 22 08:28:10 DietPi mysqld[7875]: read_buffer_size=131072
Feb 22 08:28:10 DietPi mysqld[7875]: max_used_connections=0
Feb 22 08:28:10 DietPi mysqld[7875]: max_threads=153
Feb 22 08:28:10 DietPi mysqld[7875]: thread_count=0
Feb 22 08:28:10 DietPi mysqld[7875]: It is possible that mysqld could use up to
Feb 22 08:28:10 DietPi mysqld[7875]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466214 K bytes of memory
Feb 22 08:28:10 DietPi mysqld[7875]: Hope that's ok; if not, decrease some variables in the equation.
Feb 22 08:28:10 DietPi mysqld[7875]: Thread pointer: 0x0
Feb 22 08:28:10 DietPi mysqld[7875]: Attempting backtrace. You can use the following information to find out
Feb 22 08:28:10 DietPi mysqld[7875]: where mysqld died. If you see no messages after this, something went
Feb 22 08:28:10 DietPi mysqld[7875]: terribly wrong...
Feb 22 08:28:10 DietPi mysqld[7875]: stack_bottom = 0x0 thread_stack 0x49000
Feb 22 08:28:10 DietPi mysqld[7875]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
Feb 22 08:28:10 DietPi mysqld[7875]: information that should help you find out what is causing the crash.
Feb 22 08:28:10 DietPi mysqld[7875]: Writing a core file...
Feb 22 08:28:10 DietPi mysqld[7875]: Working directory at /mnt/HD1T/dietpi_userdata/mysql
Feb 22 08:28:10 DietPi mysqld[7875]: Resource Limits:
Feb 22 08:28:10 DietPi mysqld[7875]: Fatal signal 11 while backtracing
Feb 22 08:28:10 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=11/SEGV
Feb 22 08:28:10 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Feb 22 08:28:10 DietPi systemd[1]: Failed to start MariaDB 10.3.27 database server.
Feb 22 08:28:16 DietPi systemd[1]: mariadb.service: Service RestartSec=5s expired, scheduling restart.
Feb 22 08:28:16 DietPi systemd[1]: mariadb.service: Scheduled restart job, restart counter is at 40228.
Feb 22 08:28:16 DietPi systemd[1]: Stopped MariaDB 10.3.27 database server.
Feb 22 08:28:16 DietPi systemd[1]: Starting MariaDB 10.3.27 database server...
Feb 22 08:28:16 DietPi mysqld[7949]: 2021-02-22 8:28:16 0 [Note] /usr/sbin/mysqld (mysqld 10.3.27-MariaDB-0+deb10u1) starting as process 7949 ...
Feb 22 08:28:16 DietPi mysqld[7949]: 2021-02-22 8:28:16 0 [Warning] Could not increase number of max_open_files to more than 16384 (request: 32186)
Feb 22 08:28:16 DietPi mysqld[7949]: /usr/sbin/mysqld: Can't create file '/var/log/mysql/error.log' (errno: 2 "No such file or directory")
Feb 22 08:28:17 DietPi mysqld[7949]: 2021-02-22 8:28:17 0 [Note] InnoDB: Using Linux native AIO
Feb 22 08:28:17 DietPi mysqld[7949]: 2021-02-22 8:28:17 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Feb 22 08:28:17 DietPi mysqld[7949]: 2021-02-22 8:28:17 0 [Note] InnoDB: Uses event mutexes
/var/log/mysql/error.log^Mreadlink /var/lib/mysql^Mreadlink -f /var/lib/mysql
Pattern not found
Hi,
there is something wrong on the last 3 command’s. Looks like it copied some special charactars ^M inside
/var/log/mysql/error.log^Mreadlink /var/lib/mysql^Mreadlink -f /var/lib/mysql
Pattern not found
But it should be
cat /var/log/mysql/error.log
readlink /var/lib/mysql
readlink -f /var/lib/mysql
Anyway, your issue seems to be the missing log file /var/log/mysql/error.log
Feb 22 08:28:16 DietPi mysqld[7949]: /usr/sbin/mysqld: Can't create file '/var/log/mysql/error.log' (errno: 2 "No such file or directory")
can you check if the directory is existing ls -la /var/log/mysql/
You’re right, ther’s no folder…
root@DietPi:~# ls -la /var/log/mysql/
ls: cannot access '/var/log/mysql/': No such file or directory
But how i can fix it, and most important, how this is happened with an update?
It’s enough to fix it, create the folder and the error.log file?
I don’t think the issue is cased by the update. Probably there is something else because /var/log is a tempfs and located in memory during run. Usually it should be save down to disk on a clean reboot and restored during boot process. It could be that something is wrong on this process and you end up with an empty /var/log on reboot. Can you check following directory and it’s content. It’s the offline storage for /var/log
ls -la /var/tmp/dietpi/logs/dietpi-ramlog_store
As well pls can you check following service responsible for restoring files during boot and to store them on disk during shutdown
systemctl status dietpi-ramlog
Here you have:
root@DietPi:~# ls -la /var/tmp/dietpi/logs/dietpi-ramlog_store
total 20
drwxr-xr-x 5 root root 4096 Feb 18 11:32 .
drwxrwxr-x 3 dietpi dietpi 4096 Feb 12 10:07 ..
drwxr-xr-x 2 root root 4096 Feb 19 08:04 apt
-rw-rw---- 1 root utmp 0 Feb 19 07:17 btmp
-rw-r--r-- 1 root root 0 Feb 12 10:03 dietpi-move_userdata.log
-rw-r--r-- 1 root root 0 Feb 19 08:17 dpkg.log
-rw------- 1 root root 0 Feb 19 10:53 fail2ban.log
-rw-rw-r-- 1 root utmp 0 Feb 19 10:52 lastlog
drwxr-x--- 2 www-data www-data 4096 Feb 12 08:53 lighttpd
-rw------- 1 root root 0 Feb 19 10:53 php7.3-fpm.log
drwx------ 2 root root 4096 Feb 12 07:17 private
-rw-rw-r-- 1 root utmp 0 Feb 19 10:53 wtmp
root@DietPi:~# systemctl status dietpi-ramlog
● dietpi-ramlog.service - DietPi-RAMlog
Loaded: loaded (/etc/systemd/system/dietpi-ramlog.service; enabled; vendor preset: enabled)
Active: active (exited) since Fri 2021-02-19 10:53:46 GMT; 3 days ago
Process: 216 ExecStartPre=/bin/mkdir -p /var/tmp/dietpi/logs (code=exited, status=0/SUCCESS)
Process: 219 ExecStart=/bin/dash -c /boot/dietpi/func/dietpi-ramlog 0 >> /var/tmp/dietpi/logs/dietpi-ramlog.log 2>&1 (code=exited, status=0/SUCCESS)
Main PID: 219 (code=exited, status=0/SUCCESS)
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
Thanks in advance for all the support!
ok it seems the database log folder is missing on dietpi-ramlog_store as well, strange
let’s try to get /var/log/mysql/ back
systemctl stop mariadb.service
mkdir /var/log/mysql/
chown mysql:adm /var/log/mysql/
chmod 2750 /var/log/mysql/
systemctl start mariadb.service
But I need to say, this dosn’t seems to be root cause for your issues. I did a test and removed /var/log/mysql/ on my test system. Interesting thing, MariaDB was still able to start-up.
Anyway, once you created the missing log folder and restarted your database, we should be able to have a look into the error.log
cat /var/log/mysql/error.log
I’ve get an error just in the first part:
root@DietPi:~# systemctl stop mariadb.service
root@DietPi:~# mkdir /var/log/mysql/
root@DietPi:~# chown mysql:adm /var/log/mysql/
root@DietPi:~# chmod 2750 /var/log/mysql/
root@DietPi:~# systemctl start mariadb.service
Job for mariadb.service failed because a fatal signal was delivered to the control process.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
the error.log should be present now. pls check cat /var/log/mysql/error.log