robyholmes

Thanks for everyone suggestions. I've pretty much given up on recovery now, it's just not responding to a lot of commands I've giving it so clearly something is amiss, most likely the SD card. So I've got a 2.5" enclosure on order so I can use a SATA SSD and I'll re-build from scratch next half term. Making sure I backup the SSD along the way.

Look at ExamWritePad software on this forum and at https://sheldnet.co.uk/examwritepad/ Fantastic software created for exactly what you need by someone who's actively responding to feedback on this forum. Couldn't ask for any more.

I'm thinking a USB 3.0 to SATA adapter and then I can use one of my many 2.5" SSDs for it. I have plenty of space to put this and makes backing it up (Clone of SDD) easy as well using my existing HDD dock.

I'd rather not have it running on my VM Host as it's meant to be monitoring the host cluster and alerting me if anything goes wrong. I've had a Pi monitoring system for a while now running Nems Linux and switched to Zabbix in the last month. I think it'll work better longer term but just a shame something, be that the OS or SD Card itself has screwed up before I backed it up.

Thank you @dmj I've managed to get a SQLdump but now I have to get it off the Pi. I don't have a monitor connection for it and I'm failing at getting SSH to copy it for me. I've really reached the end of my knowledge, especially on a friday! Zabbix does work very a short while if you reboot the Pi, but soon stops again.

Recovery Mode 3 has got it started by the look of it, but Zabbix can't connect. ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ An ExecStart= process belonging to unit mariadb.service has exited. ░░ ░░ The process' exit code is 'killed' and its exit status is 11. May 20 12:59:57 raspberrypi systemd[1]: mariadb.service: Failed with result 'signal'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ The unit mariadb.service has entered the 'failed' state with result 'signal'. May 20 12:59:57 raspberrypi systemd[1]: mariadb.service: Consumed 1.292s CPU time. ░░ Subject: Resources consumed by unit runtime ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ The unit mariadb.service completed and consumed the indicated resources. May 20 13:00:02 raspberrypi systemd[1]: mariadb.service: Scheduled restart job, restart counter is at 874. ░░ Subject: Automatic restarting of a unit has been scheduled ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ Automatic restarting of the unit mariadb.service has been scheduled, as the result for ░░ the configured Restart= setting for the unit. May 20 13:00:02 raspberrypi systemd[1]: Stopped MariaDB 10.5.15 database server. ░░ Subject: A stop job for unit mariadb.service has finished ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A stop job for unit mariadb.service has finished. ░░ ░░ The job identifier is 58978 and the job result is done. May 20 13:00:02 raspberrypi systemd[1]: mariadb.service: Consumed 1.292s CPU time. ░░ Subject: Resources consumed by unit runtime ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ The unit mariadb.service completed and consumed the indicated resources. May 20 13:00:02 raspberrypi systemd[1]: Starting MariaDB 10.5.15 database server... ░░ Subject: A start job for unit mariadb.service has begun execution ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit mariadb.service has begun execution. ░░ ░░ The job identifier is 58978. May 20 13:00:02 raspberrypi mariadbd[27166]: 2022-05-20 13:00:02 0 [Note] /usr/sbin/mariadbd (mysqld 10.5.15-MariaDB-0+deb11u1) starting as process 27166 ... May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: !!! innodb_force_recovery is set to 3 !!! May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Uses event mutexes May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Number of pools: 1 May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Using generic crc32 instructions May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Using Linux native AIO May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Completed initialization of buffer pool May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=65124827976,65124827976 May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: 2 transaction(s) which must be rolled back or cleaned up in total 350 row operations to undo May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Trx id counter is 48717236 May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Starting final batch to recover 1146 pages from redo log. May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: 128 rollback segments are active. May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Creating shared tablespace for temporary tables May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: 10.5.15 started; log sequence number 65126821965; transaction id 48717236 May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] Plugin 'FEEDBACK' is disabled. May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] Server socket created on IP: '127.0.0.1'. May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] Reading of all Master_info entries succeeded May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] Added new Master_info '' to hash table May 20 13:00:03 raspberrypi mariadbd[27166]: 2022-05-20 13:00:03 0 [Note] /usr/sbin/mariadbd: ready for connections. May 20 13:00:03 raspberrypi mariadbd[27166]: Version: '10.5.15-MariaDB-0+deb11u1' socket: '/run/mysqld/mysqld.sock' port: 3306 Raspbian 11 May 20 13:00:03 raspberrypi systemd[1]: Started MariaDB 10.5.15 database server. ░░ Subject: A start job for unit mariadb.service has finished successfully ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit mariadb.service has finished successfully. ░░ ░░ The job identifier is 58978. May 20 13:00:03 raspberrypi /etc/mysql/debian-start[27188]: Upgrading MySQL tables if necessary. May 20 13:00:03 raspberrypi /etc/mysql/debian-start[27191]: /usr/bin/mysql_upgrade: unknown variable 'innodb_force_recovery=3' May 20 13:00:03 raspberrypi /etc/mysql/debian-start[27192]: Checking for insecure root accounts. May 20 13:00:04 raspberrypi mariadbd[27166]: 2022-05-20 13:00:04 3 [Warning] Access denied for user 'root'@'localhost' (using password: NO) May 20 13:00:04 raspberrypi debian-start[27195]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO) May 20 13:00:04 raspberrypi mariadbd[27166]: 2022-05-20 13:00:04 0 [Note] InnoDB: Buffer pool(s) load completed at 220520 13:00:04

May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] /usr/sbin/mariadbd (mysqld 10.5.15-MariaDB-0+deb11u1) starting as process 14825 ... May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: !!! innodb_force_recovery is set to 1 !!! May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Uses event mutexes May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Number of pools: 1 May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Using generic crc32 instructions May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Using Linux native AIO May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Completed initialization of buffer pool May 20 12:40:19 raspberrypi mariadbd[14825]: 2022-05-20 12:40:19 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=65124827976,65124827976 May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: 2 transaction(s) which must be rolled back or cleaned up in total 350 row operations to undo May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: Trx id counter is 48717101 May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: Starting final batch to recover 935 pages from redo log. May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: 128 rollback segments are active. May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: Starting in background the rollback of recovered transactions May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: Creating shared tablespace for temporary tables May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. May 20 12:40:20 raspberrypi mariadbd[14825]: 2022-05-20 12:40:20 0 [ERROR] [FATAL] InnoDB: InnoDB is trying to free page [page id: space=76, page number=64] though it is already marked as free in the tablespace! The tablespace free space info is corrupt. You may need to dump your tables and recreate the whole database!Please refer to https://mariadb.com/kb/en/library/innodb-rec> May 20 12:40:20 raspberrypi mariadbd[14825]: 220520 12:40:20 [ERROR] mysqld got signal 6 ; May 20 12:40:20 raspberrypi mariadbd[14825]: This could be because you hit a bug. It is also possible that this binary May 20 12:40:20 raspberrypi mariadbd[14825]: or one of the libraries it was linked against is corrupt, improperly built, May 20 12:40:20 raspberrypi mariadbd[14825]: or misconfigured. This error can also be caused by malfunctioning hardware. May 20 12:40:20 raspberrypi mariadbd[14825]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs May 20 12:40:20 raspberrypi mariadbd[14825]: We will try our best to scrape up some info that will hopefully help May 20 12:40:20 raspberrypi mariadbd[14825]: diagnose the problem, but since we have already crashed, May 20 12:40:20 raspberrypi mariadbd[14825]: something is definitely wrong and this may fail. May 20 12:40:20 raspberrypi mariadbd[14825]: Server version: 10.5.15-MariaDB-0+deb11u1 May 20 12:40:20 raspberrypi mariadbd[14825]: key_buffer_size=134217728 May 20 12:40:20 raspberrypi mariadbd[14825]: read_buffer_size=131072 May 20 12:40:20 raspberrypi mariadbd[14825]: max_used_connections=0 May 20 12:40:20 raspberrypi mariadbd[14825]: max_threads=153 May 20 12:40:20 raspberrypi mariadbd[14825]: thread_count=0 May 20 12:40:20 raspberrypi mariadbd[14825]: It is possible that mysqld could use up to May 20 12:40:20 raspberrypi mariadbd[14825]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466524 K bytes of memory May 20 12:40:20 raspberrypi mariadbd[14825]: Hope that's ok; if not, decrease some variables in the equation. May 20 12:40:20 raspberrypi mariadbd[14825]: Thread pointer: 0x0 May 20 12:40:20 raspberrypi mariadbd[14825]: Attempting backtrace. You can use the following information to find out May 20 12:40:20 raspberrypi mariadbd[14825]: where mysqld died. If you see no messages after this, something went May 20 12:40:20 raspberrypi mariadbd[14825]: terribly wrong... May 20 12:40:20 raspberrypi mariadbd[14825]: stack_bottom = 0x0 thread_stack 0x49000 May 20 12:40:20 raspberrypi mariadbd[14825]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains May 20 12:40:20 raspberrypi mariadbd[14825]: information that should help you find out what is causing the crash. May 20 12:40:20 raspberrypi mariadbd[14825]: Writing a core file... May 20 12:40:20 raspberrypi mariadbd[14825]: Working directory at /var/lib/mysql May 20 12:40:20 raspberrypi mariadbd[14825]: Resource Limits: May 20 12:40:20 raspberrypi mariadbd[14825]: Limit Soft Limit Hard Limit Units May 20 12:40:20 raspberrypi mariadbd[14825]: Max cpu time unlimited unlimited seconds May 20 12:40:20 raspberrypi mariadbd[14825]: Max file size unlimited unlimited bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max data size unlimited unlimited bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max stack size 8388608 unlimited bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max core file size 0 unlimited bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max resident set unlimited unlimited bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max processes 12402 12402 processes May 20 12:40:20 raspberrypi mariadbd[14825]: Max open files 32768 32768 files May 20 12:40:20 raspberrypi mariadbd[14825]: Max locked memory 65536 65536 bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max address space unlimited unlimited bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max file locks unlimited unlimited locks May 20 12:40:20 raspberrypi mariadbd[14825]: Max pending signals 12402 12402 signals May 20 12:40:20 raspberrypi mariadbd[14825]: Max msgqueue size 819200 819200 bytes May 20 12:40:20 raspberrypi mariadbd[14825]: Max nice priority 0 0 May 20 12:40:20 raspberrypi mariadbd[14825]: Max realtime priority 0 0 May 20 12:40:20 raspberrypi mariadbd[14825]: Max realtime timeout unlimited unlimited us May 20 12:40:20 raspberrypi mariadbd[14825]: Core pattern: core May 20 12:40:20 raspberrypi sudo[14840]: pi : TTY=pts/0 ; PWD=/etc/mysql ; USER=root ; COMMAND=/bin/systemctl start mariadb May 20 12:40:20 raspberrypi sudo[14840]: pam_unix(sudo:session): session opened for user root(uid=0) by pi(uid=1000) May 20 12:40:20 raspberrypi systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT Edit: Found the file /etc/ mysql/ my.cnf and put the recovery mode in that but it's not solved it I'm afraid.

I did read this a few times but I couldn't work out where to put it. All the paths I found the file was either blank or didn't exist.

Hi All, Could I ask for assistance from any Linux experts to help me resolve a problem with my Pi 4 Zabbix system. I've been building it for a while now and it's been going very well. Yesterday I finished the configuration and updated to Zabbix 6.0. Zabbix started fine and it was back monitoring before I left work. I was already running late so I didn't back up the SD card as I planned on doing that this morning. However around midnight the Zabbix database stopped and now won't start. MariaDB is reporting the following now: May 20 10:01:30 raspberrypi systemd[1]: Stopped MariaDB 10.5.15 database server. ░░ Subject: A stop job for unit mariadb.service has finished ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A stop job for unit mariadb.service has finished. ░░ ░░ The job identifier is 44146 and the job result is done. May 20 10:01:30 raspberrypi systemd[1]: Starting MariaDB 10.5.15 database server... ░░ Subject: A start job for unit mariadb.service has begun execution ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit mariadb.service has begun execution. ░░ ░░ The job identifier is 44146. May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] /usr/sbin/mariadbd (mysqld 10.5.15-MariaDB-0+deb11u1) starting as process 11820 ... May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Uses event mutexes May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Number of pools: 1 May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Using generic crc32 instructions May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Using Linux native AIO May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Completed initialization of buffer pool May 20 10:01:30 raspberrypi mariadbd[11820]: 2022-05-20 10:01:30 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=65124827976,65124827976 May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: 2 transaction(s) which must be rolled back or cleaned up in total 350 row operations to undo May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: Trx id counter is 48717101 May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: Starting final batch to recover 935 pages from redo log. May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: 128 rollback segments are active. May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: Starting in background the rollback of recovered transactions May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: Creating shared tablespace for temporary tables May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... May 20 10:01:31 raspberrypi mariadbd[11820]: 2022-05-20 10:01:31 0 [ERROR] [FATAL] InnoDB: InnoDB is trying to free page [page id: space=76, page number=64] though it is already marked as > May 20 10:01:31 raspberrypi mariadbd[11820]: 220520 10:01:31 [ERROR] mysqld got signal 6 ; May 20 10:01:31 raspberrypi mariadbd[11820]: This could be because you hit a bug. It is also possible that this binary May 20 10:01:31 raspberrypi mariadbd[11820]: or one of the libraries it was linked against is corrupt, improperly built, May 20 10:01:31 raspberrypi mariadbd[11820]: or misconfigured. This error can also be caused by malfunctioning hardware. May 20 10:01:31 raspberrypi mariadbd[11820]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs May 20 10:01:31 raspberrypi mariadbd[11820]: We will try our best to scrape up some info that will hopefully help May 20 10:01:31 raspberrypi mariadbd[11820]: diagnose the problem, but since we have already crashed, May 20 10:01:31 raspberrypi mariadbd[11820]: something is definitely wrong and this may fail. May 20 10:01:31 raspberrypi mariadbd[11820]: Server version: 10.5.15-MariaDB-0+deb11u1 May 20 10:01:31 raspberrypi mariadbd[11820]: key_buffer_size=134217728 May 20 10:01:31 raspberrypi mariadbd[11820]: read_buffer_size=131072 May 20 10:01:31 raspberrypi mariadbd[11820]: max_used_connections=0 May 20 10:01:31 raspberrypi mariadbd[11820]: max_threads=153 May 20 10:01:31 raspberrypi mariadbd[11820]: thread_count=0 May 20 10:01:31 raspberrypi mariadbd[11820]: It is possible that mysqld could use up to May 20 10:01:31 raspberrypi mariadbd[11820]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466524 K bytes of memory May 20 10:01:31 raspberrypi mariadbd[11820]: Hope that's ok; if not, decrease some variables in the equation. May 20 10:01:31 raspberrypi mariadbd[11820]: Thread pointer: 0x0 May 20 10:01:31 raspberrypi mariadbd[11820]: Attempting backtrace. You can use the following information to find out May 20 10:01:31 raspberrypi mariadbd[11820]: where mysqld died. If you see no messages after this, something went May 20 10:01:31 raspberrypi mariadbd[11820]: terribly wrong... May 20 10:01:31 raspberrypi mariadbd[11820]: stack_bottom = 0x0 thread_stack 0x49000 May 20 10:01:31 raspberrypi mariadbd[11820]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains May 20 10:01:31 raspberrypi mariadbd[11820]: information that should help you find out what is causing the crash. May 20 10:01:31 raspberrypi mariadbd[11820]: Writing a core file... May 20 10:01:31 raspberrypi mariadbd[11820]: Working directory at /var/lib/mysql May 20 10:01:31 raspberrypi mariadbd[11820]: Resource Limits: May 20 10:01:31 raspberrypi mariadbd[11820]: Limit Soft Limit Hard Limit Units May 20 10:01:31 raspberrypi mariadbd[11820]: Max cpu time unlimited unlimited seconds May 20 10:01:31 raspberrypi mariadbd[11820]: Max file size unlimited unlimited bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max data size unlimited unlimited bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max stack size 8388608 unlimited bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max core file size 0 unlimited bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max resident set unlimited unlimited bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max processes 12402 12402 processes May 20 10:01:31 raspberrypi mariadbd[11820]: Max open files 32768 32768 files May 20 10:01:31 raspberrypi mariadbd[11820]: Max locked memory 65536 65536 bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max address space unlimited unlimited bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max file locks unlimited unlimited locks May 20 10:01:31 raspberrypi mariadbd[11820]: Max pending signals 12402 12402 signals May 20 10:01:31 raspberrypi mariadbd[11820]: Max msgqueue size 819200 819200 bytes May 20 10:01:31 raspberrypi mariadbd[11820]: Max nice priority 0 0 May 20 10:01:31 raspberrypi mariadbd[11820]: Max realtime priority 0 0 May 20 10:01:31 raspberrypi mariadbd[11820]: Max realtime timeout unlimited unlimited us May 20 10:01:31 raspberrypi mariadbd[11820]: Core pattern: core May 20 10:01:31 raspberrypi systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ An ExecStart= process belonging to unit mariadb.service has exited. ░░ ░░ The process' exit code is 'killed' and its exit status is 6. May 20 10:01:31 raspberrypi systemd[1]: mariadb.service: Failed with result 'signal'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ The unit mariadb.service has entered the 'failed' state with result 'signal'. May 20 10:01:31 raspberrypi systemd[1]: Failed to start MariaDB 10.5.15 database server. ░░ Subject: A start job for unit mariadb.service has failed ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit mariadb.service has finished with a failure. ░░ So it looks like I have corruption in my database, but google doesn't seem to be helping me as I think I need to drop the tables and re-import? Would someone be willing to offer advice or PM me to get in touch and go from there? Thank you, Rob Holmes

That's very interesting. It's not really a long term solution but does prove our problems are the same. Could I ask you to post or PM me your Smoothwall case number as I'd like to as Smoothwall to look at both cases as it appears we have the same bug. @ibpalle could you pass this on from your side of things please?

We created a new policy and set it to 'Do not inspect'. Just as a temporary test to see if it solves the problem. If it does, it means my issue which is staff being blocked from websites allowed for the staff group is the same as yours.

Did you try adding YouTube to a 'Don't inspect' HTTPS rule to see if it fixes it? We had 2nd line look at our Smoothwall and we found anything not being inspected worked correctly, but as soon as you inspect it we'd have things go through the filter with no group information (But username info, showing authentication working). This would account for students being allowed YouTube if you block it via a group.

Did anyone try this? Did it make a difference?

Interesting. Can you add a rule too decrypt and inspect to not inspect YouTube and see if it fixes the issue? I have a feeling it might (Although not a solution of course, but intestering to see).

How are people blocking YouTube? Do you have it default blocked then allow staff, or default allowed then block students? We're having random issues with authenticated users not been put in to the groups. As we default block YouTube students aren't getting on, but staff are being blocked randomly with the group on the block page shown as 'N/A'. Smoothwall are trying to replicate it there side of things to see if it's a bug. I'm wondering if the issues you are seeing could be linked if you block it via a group. IE when students get access, it's because they don't have a group of 'Pupils' or 'Students'.

Just out of interest, do you block Youtube by default in your core blocked rule (Bottom of the list), or do you block it on the Pupils group? IE, do you allow staff / visitors access, or do you allow everyone but block pupils?

We're having problems accessing YouTube for staff. Smoothwall logs show much requests from staff usernames have group information, some however are blank and they get a YouTube block. Refresh the page or try the link a few times and you get lucky. I couldn't be that the group information missing from staff is being attached to students could it?

Seems to be a common problem around the key change over times for us. Our broadband supply coping fine and it's not ever day, but I do keep logging it with Bromcom as it seems they are just a bit tight on server performance.

It's not Word, but look at ExamWritePad on this forum. It's been designed for this very reason and the number of options you can set to make it work for you is amazing! It's made providing laptops for exams so much easier. Best feature of all is it autosaves every minute (Configurable, of course) We then log laptops on before the exam, ExamWritePad opens full screen with a password to exit it.

Thanks everyone! What I've come to realise with this thread, is that I should be grateful the keyboards are lasting long enough to wear the cables out, rather than be damaged! Ha

It's not breaking at the pc cover end, it's at the keyboard end as it goes in to the keyboard casing.

We're not getting much damage to be fair to them. They just pull the keyboards about and we have the cables inside a VeryPC micro cable cover so they don't pull out. So the weak point is now the strain relief on the keyboard itself.

Hi All, This year we have down to replace the keyboard and mice in one of our ICT Suites as the students have pulled to much at the cables and we're having a lot of USB issues. Can anyone suggest a good keyboard and mouse (Either pack or each) which is student resistant? Mainly on cable strain relief, we don't have many students swapping keys thankfully (Touch wood). I've said resistant as we all know, nothing is student proof! Thanks in advanced, Rob

Freshdesk here for both IT and Site

As for DHCP on Smoothwall. Yes it does.