HTTP ERROR 599 after upgrade

Having issues with your DietPi installation or found a bug? Post it here.
Fabio
Posts: 38
Joined: Fri Dec 18, 2020 2:43 pm

Re: HTTP ERROR 599 after upgrade

Post by Fabio »

Hello @Joulinar,
sorry for the daly in my reply.
I've checked the status

Code: Select all

dietpi-services status
, and this is what i get:

Code: Select all

[  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)
User avatar
Joulinar
Posts: 4804
Joined: Sat Nov 16, 2019 12:49 am

Re: HTTP ERROR 599 after upgrade

Post by Joulinar »

there you go, your MariaDB is not in active status. Therefore Owncloud is not able to connect and run. Pls share following

Code: Select all

systemctl restart mariadb.service
journalctl -u mariadb
cat /var/log/mysql/error.log
readlink /var/lib/mysql
readlink -f /var/lib/mysql
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Fabio
Posts: 38
Joined: Fri Dec 18, 2020 2:43 pm

Re: HTTP ERROR 599 after upgrade

Post by Fabio »

Here you have!

Code: Select all

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
User avatar
Joulinar
Posts: 4804
Joined: Sat Nov 16, 2019 12:49 am

Re: HTTP ERROR 599 after upgrade

Post by Joulinar »

Hi,

there is something wrong on the last 3 command's. Looks like it copied some special charactars ^M inside

Code: Select all

/var/log/mysql/error.log^Mreadlink /var/lib/mysql^Mreadlink -f /var/lib/mysql
Pattern not found
But it should be

Code: Select all

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

Code: Select all

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/
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Fabio
Posts: 38
Joined: Fri Dec 18, 2020 2:43 pm

Re: HTTP ERROR 599 after upgrade

Post by Fabio »

You're right, ther's no folder...

Code: Select all

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? :roll:

It's enough to fix it, create the folder and the error.log file?
User avatar
Joulinar
Posts: 4804
Joined: Sat Nov 16, 2019 12:49 am

Re: HTTP ERROR 599 after upgrade

Post by Joulinar »

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

Code: Select all

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

Code: Select all

systemctl status dietpi-ramlog
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Fabio
Posts: 38
Joined: Fri Dec 18, 2020 2:43 pm

Re: HTTP ERROR 599 after upgrade

Post by Fabio »

Here you have:

Code: Select all

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

Code: Select all

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!
User avatar
Joulinar
Posts: 4804
Joined: Sat Nov 16, 2019 12:49 am

Re: HTTP ERROR 599 after upgrade

Post by Joulinar »

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

Code: Select all

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

Code: Select all

cat /var/log/mysql/error.log
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Fabio
Posts: 38
Joined: Fri Dec 18, 2020 2:43 pm

Re: HTTP ERROR 599 after upgrade

Post by Fabio »

I've get an error just in the first part:

Code: Select all

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.
User avatar
Joulinar
Posts: 4804
Joined: Sat Nov 16, 2019 12:49 am

Re: HTTP ERROR 599 after upgrade

Post by Joulinar »

the error.log should be present now. pls check cat /var/log/mysql/error.log
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Post Reply