[debian-mysql] Bug#829491: mariadb-server-10.0: Removes lost+found directory if purged, /var/lib/mysql is a mountpoint with an ext4 filesystem, and user requests to remove all databases

[Axel Beckert]

Package: mariadb-server-10.0
Version: 10.0.26-1

Dear Maintainer,

purging mariadb-server-10.0 (or maybe mariadb-server-core-10.0 is the
culprit, not sure) while /var/lib/mysql is a mountpoint with an ext4
filesystem behaves a little bit schizophrenic:

It of course fails to remove /var/lib/mysql/ if I explicitly answer it's
question about the removal of all databases with "Yes":

rm: cannot remove '/var/lib/mysql': Device or resource busy
dpkg: error processing package mariadb-server-10.0 (--purge):
 subprocess installed post-removal script returned error exit status 1

(This IMHO shouldn't make the uninstallation fail.)

But it also leaves quite some clutter in there:

13/0/0 root at c6:pts/37 20:28:14 [/var/lib/mysql] # ls -l
total 110624
-rw-rw---- 1 mysql mysql    16384 Jul  3 20:39 aria_log.00000001
-rw-rw---- 1 mysql mysql       52 Jul  3 20:39 aria_log_control
-rw-r--r-- 1 root  root         0 Jul  3 20:39 debian-10.0.flag
-rw-rw---- 1 mysql mysql 50331648 Jul  3 20:39 ib_logfile0
-rw-rw---- 1 mysql mysql 50331648 Jul  3 20:37 ib_logfile1
-rw-rw---- 1 mysql mysql 12582912 Jul  3 20:39 ibdata1
-rw-rw---- 1 mysql mysql        0 Jul  3 20:39 multi-master.info
drwx------ 2 mysql root      4096 Jul  3 20:39 mysql
-rw------- 1 root  root        15 Jul  3 20:39 mysql_upgrade_info
drwx------ 2 mysql mysql     4096 Jul  3 20:39 performance_schema

It though managed somehow to remove /var/lib/mysql/lost+found/ which
contains file system related data and no databases, hence should not be
removed when the user agrees to have all databases removed. Before
purging the package, the directory looked like this:

12/0/0 root at c6:pts/37 20:24:39 [/var/lib/mysql] # ls -la
total 110632
drwx------   5 mysql mysql     4096 Jul  3 20:25 .
drwxr-xr-x 113 root  root      4096 Jul  3 20:24 ..
-rw-rw----   1 mysql mysql    16384 Jul  3 20:25 aria_log.00000001
-rw-rw----   1 mysql mysql       52 Jul  3 20:25 aria_log_control
-rw-r--r--   1 root  root         0 Jul  3 20:24 debian-10.0.flag
-rw-rw----   1 mysql mysql 50331648 Jul  3 20:25 ib_logfile0
-rw-rw----   1 mysql mysql 50331648 Jul  3 20:24 ib_logfile1
-rw-rw----   1 mysql mysql 12582912 Jul  3 20:25 ibdata1
drwx------   2 mysql mysql     4096 Jul  3 20:13 lost+found
-rw-rw----   1 mysql mysql        0 Jul  3 20:25 multi-master.info
drwx------   2 mysql root      4096 Jul  3 20:25 mysql
drwx------   2 mysql mysql     4096 Jul  3 20:24 performance_schema

This is similar (but probably unrelated) to mysql-server's ancient, but
never fixed bug #608938. (Actually I found this bug when I checked if
MariaDB is also affected by #608938 after it had been prematurely
closed.)

I'm totally unsure about which severity this issue should get as some
aspects (unexpected data loss) would speak for some RC severity, but
then again, this only happens if all other data in that directory is,
well, should be removed anyways, so any potentially saved data from some
fsck is probably no more needed either. That way it should be probably
minor. Then again, it can make the package fail to be removed, which is
surely not minor. So I'm staying with the default severity. Feel free to
change it.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)