Open MartinDeppe opened 4 years ago
@MartinDeppe Many thanks for your report.
Indeed this issue was reported by times, sadly we could never replicate, hence not find out why this works fine in 99% of systems but fails in 1%.
We symlink the MariaDB database location from default /var/lib/mysql
to /mnt/dietpi_userdata/mysql
. Since usually on SBCs the system is on SDcard, the default database location is on SDcard. Database writes are usually very regular and heavy, e.g. typical Nextcloud oc_filescache database table file is easily hundrets of MiB large and can be rewritten on every access, hence every tiny change to any Nextcloud file or meta data. These kind of heavy regular writes kill SDcards quickly, which is the most common issues for system crashes, data loss etc... So we put database dir to DietPi userdata by default, since this can be moved easily to an external drive, which can handle database I/O much more reliable and faster.
I found users running into MariaDB startup in very rare cases when the DietPi userdata were indeed moved to an external drive. Is this true in your case as well, and can you paste the following:
df -T # Only external userdata mount line required
ls -al /mnt/dietpi_userdata/mysql # To check permissions/ownership etc
I know that AppArmor rules can deny access through symlinks in general. Do you have either AppArmor or SELinux installed?
Hello MichaIng/DietPi,
man thanks for your reply. You guessed right, I am running it on an external (magnetic) Hard-Disk, so that the writes to the SD-Card are actually minimized to updates of the operating system or any other software.
I give you even some more information than you requested. I think that will help you even more:
root@pi30:~# df -T
Dateisystem Typ 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root ext4 102687672 1898664 100772624 2% /
devtmpfs devtmpfs 494908 0 494908 0% /dev
tmpfs tmpfs 499516 0 499516 0% /dev/shm
tmpfs tmpfs 499516 12876 486640 3% /run
tmpfs tmpfs 5120 0 5120 0% /run/lock
tmpfs tmpfs 499516 0 499516 0% /sys/fs/cgroup
/dev/sda4 ext4 848376672 9655296 795556500 2% /home
tmpfs tmpfs 51200 16 51184 1% /var/log
tmpfs tmpfs 499712 0 499712 0% /tmp
tmpfs tmpfs 10240 1396 8844 14% /DietPi
/dev/mmcblk0p1 vfat 44220 24246 19974 55% /boot
tmpfs tmpfs 99900 0 99900 0% /run/user/0
root@pi30:~# ls -al /mnt/dietpi_userdata/mysql
insgesamt 176184
drwxrwx--- 7 mysql mysql 4096 Dez 3 15:02 .
drwxrwxr-x 9 dietpi dietpi 4096 Mai 14 2019 ..
-rwxrwx--- 1 mysql mysql 16384 Dez 3 15:02 aria_log.00000001
-rwxrwx--- 1 mysql mysql 52 Dez 3 15:02 aria_log_control
-rwxrwx--- 1 mysql mysql 0 Mai 4 2019 debian-10.1.flag
-rwxrwx--- 1 mysql mysql 79691776 Dez 3 15:02 ibdata1
-rwxrwx--- 1 mysql mysql 50331648 Dez 3 15:02 ib_logfile0
-rwxrwx--- 1 mysql mysql 50331648 Mai 13 2019 ib_logfile1
drwxrwx--- 2 mysql mysql 4096 Mai 13 2019 mts
-rwxrwx--- 1 mysql mysql 0 Apr 20 2019 multi-master.info
drwxrwx--- 2 mysql mysql 4096 Mai 4 2019 mysql
drwxrwx--- 2 mysql mysql 12288 Mai 6 2019 nextcloud
drwxrwx--- 2 mysql mysql 4096 Mai 4 2019 performance_schema
drwx------ 2 mysql mysql 4096 Dez 3 14:55 schutz_drk
root@pi30:~# ls -al /var/lib/mysql
insgesamt 176212
drwxrwx--- 7 mysql mysql 4096 Dez 3 15:09 .
drwxr-xr-x 28 root root 4096 Dez 2 04:07 ..
-rwxrwx--- 1 mysql mysql 16384 Dez 3 15:02 aria_log.00000001
-rwxrwx--- 1 mysql mysql 52 Dez 3 15:02 aria_log_control
-rwxrwx--- 1 mysql mysql 0 Mai 4 2019 debian-10.1.flag
-rwxrwx--- 1 mysql mysql 79691776 Dez 4 21:53 ibdata1
-rwxrwx--- 1 mysql mysql 50331648 Dez 4 21:53 ib_logfile0
-rwxrwx--- 1 mysql mysql 50331648 Mai 13 2019 ib_logfile1
drwxrwx--- 2 mysql mysql 4096 Mai 13 2019 mts
-rwxrwx--- 1 mysql mysql 0 Apr 20 2019 multi-master.info
drwxrwx--- 2 mysql mysql 4096 Mai 4 2019 mysql
drwxrwx--- 2 mysql mysql 12288 Mai 6 2019 nextcloud
drwxrwx--- 2 mysql mysql 4096 Mai 4 2019 performance_schema
drwx------ 2 mysql mysql 4096 Dez 3 17:24 schutz_drk
-rw-rw---- 1 mysql mysql 24576 Dez 3 15:09 tc.log
root@pi30:~# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat E889-F26F
├─sda2 swap a95ada14-3f79-4964-adae-783ec691b76e [SWAP]
├─sda3 ext4 c2cfd4d0-e7fe-46ab-8cfa-f897342420e6 /
└─sda4 ext4 511dec91-70f9-46f2-9f54-285bccf75c2e /home
mmcblk0
├─mmcblk0p1 vfat boot 9304-D9FD /boot
└─mmcblk0p2 ext4 rootfs 29075e46-f0d4-44e2-a9e7-55ac02d6e6cc
root@pi30:~#
Can I configure this behaviour into not using a symbolic link? I would highly appreciate, if it would be configurable via dietpi-config or so.
By the way, I needed to install apache2 (for nextcloud), which actually might be the reason for the problem, since it isn't integrated well enough as it seems. The hard thing for me to confront was, that by trying to install "phpmyadmin" the process removed my at that time current databases completely. It is running again, but I lost all configurations made since the last version I had.
It seems that neither AppArmor nor selinux are installed (obviously) and I never worked with AppArmor yet:
root@pi30:~# dpkg -l | egrep -i 'apparmor|selinux'
ii libapparmor1:armhf 2.11.0-3+deb9u2 armhf changehat AppArmor library
ii libselinux1:armhf 2.6-3 armhf SELinux runtime shared libraries
ii libsemanage-common 2.6-2 all Common files for SELinux policy management libraries
ii libsemanage1:armhf 2.6-2 armhf SELinux policy management library
ii libsepol1:armhf 2.6-2 armhf SELinux library for manipulating binary security policies
When I installed DietPi on my Raspberry, I didn't get it to work by using a symlink to the new location. The effect was, that mariadb didn't start with a symlink, IIRC.
I hope that helps you and me Martin
Am 04.12.19 um 17:40 schrieb MichaIng:
@MartinDeppe https://github.com/MartinDeppe Many thanks for your report.
Indeed this issue was reported by times, sadly we could never replicate, hence not find out why this works fine in 99% of systems but fails in 1%.
Background
We symlink the MariaDB database location from default |/var/lib/mysql| to |/mnt/dietpi_userdata/mysql|. Since usually on SBCs the system is on SDcard, the default database location is on SDcard. Database writes are usually very regular and heavy, e.g. typical Nextcloud oc_filescache database table file is easily hundrets of MiB large and can be rewritten on every access, hence every tiny change to any Nextcloud file or meta data. These kind of heavy regular writes kill SDcards quickly, which is the most common issues for system crashes, data loss etc... So we put database dir to DietPi userdata by default, since this can be moved easily to an external drive, which can handle database I/O much more reliable and faster.
I found users running into MariaDB startup in very rare cases when the DietPi userdata were indeed moved to an external drive. Is this true in your case as well, and can you paste the following:
|df -T # Only external userdata mount line required ls -al /mnt/dietpi_userdata/mysql # To check permissions/ownership etc |
I know that AppArmor rules can deny access through symlinks in general. Do you have either AppArmor or SELinux installed?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/3249?email_source=notifications&email_token=AN5R2PUFLK25Y6OD2CW22BTQW7MPVA5CNFSM4JTNGFG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5UUTI#issuecomment-561728077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN5R2PSU24K7OA6NSVJPUJLQW7MPVANCNFSM4JTNGFGQ.
@MartinDeppe
/dev/sda4 ext4 848376672 9655296 795556500 2% /home
I think that is the issue.
2019-12-04 23:21:13 root@micha:/var/log# systemctl cat mariadb | grep ProtectHome
ProtectHome=true
ProtectHome=true
flag, which blocks access to anything in the /home
dir./var/lib/<name>
usually on UNIX systems and in cases to /mnt/dietpi_userdata/<name>
on DietPi particularly./home
is ONLY for login users and their very personal data. Only user services, started by a non-root login user account, are intended to write to their home dirs as well.Mount the external drive to /mnt/<something>
instead, adjust the /mnt/dietpi_userdata
symlink accordingly and MariaDB should start fine 🙂. Btw now that I see this, I remember this being the issue in the other case as well 😄.
Details:
#1253 SMP Thu Aug 15 11:49:46 BST 2019
Steps to reproduce:
Expected behaviour:
Actual behaviour:
Extra details:
Additional logs: