Description of problem: "systemctl start mysqld.service" end with an error: mysqld.service: Start request repeated too quickly. Version-Release number of selected component (if applicable): How reproducible: try to start mysqld Steps to Reproduce: 1. 2. 3. Workaround: create a directory /var/run/mysqld and give it to mysql user: mkdir -p /var/run/mysqld chown mysql:mysql /var/run/mysqld systemctl start mysqld.service
Summary: mysqld don't start => mysqld doesn't start
Do you have all updates installed? Just tested on a new install with mariadb-10.5.5-1.mga8, and it started ok. /var/run is a symlink to /run which is mounted as a tmpf. /run/mysqld exists owned by mysql:mysql It's created during boot based on the contents of /usr/lib/tmpfiles.d/mysql.conf.
CC: (none) => davidwhodgins
Confirmed what Dave says. On an up-to date Mageia 8 system with MariaDB installed but not running: $ rpm -q mariadb-core [contains 'mysqld' binary] mariadb-core-10.5.5-1.mga8 $ ls -l /run drwxr-xr-x 2 mysql mysql 40 Aws 20 20:21 mysqld/ but the directory is empty. $ sudo systemctl status mysqld [sudo] password for lewis: ● mysqld.service - MySQL database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; vendor p> Active: inactive (dead) $ sudo systemctl start mysqld $ sudo systemctl status mysqld ● mysqld.service - MySQL database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; vendor p> Active: active (running) since Thu 2020-08-20 21:07:25 CEST; 3s ago Process: 7356 ExecStartPre=/usr/sbin/mysqld-prepare-db-dir (code=exited, st> Main PID: 7434 (mysqld) Status: "Taking your SQL requests now..." Tasks: 13 (limit: 4361) Memory: 72.3M CPU: 1.140s CGroup: /system.slice/mysqld.service └─7434 /usr/sbin/mysqld ... Aws 20 21:07:25 localhost.localdomain mysqld[7434]: Version: '10.5.5-MariaDB' > Aws 20 21:07:25 localhost.localdomain systemd[1]: Started MySQL database server. $ sudo systemctl stop mysqld
Source RPM: (none) => mariadb-10.5.5-1.mga8.src.rpmEver confirmed: 1 => 0Status: NEW => UNCONFIRMEDCC: (none) => lewyssmith
Sorry that mariadb does not work on your system. But, have you execute "mysql_update" command in console as root as recommended upstream after an update? "When upgrading from MariaDB 10.3.8 or earlier to MariaDB 10.3.9 or higher, running "mysql_upgrade" is required due to changes introduced in MDEV-14637." Best regards,
CC: (none) => ouaurelien
@ Aurelien I don't remember whether or not I ran mysql_update when updating to 10.3.9. Anyway there no mysql_update script on my system and I did not find any either in cauldron packages (urpmf mysql_update return nothing). @Dave & Lewis I confirm that every mariadb package are updated. /var/run is a symbolic link to /run. /usr/lib/tmpfiles.d/mysql.conf exists and contain a line: d /run/mysqld 0755 mysql mysql - /run/mysqld does not exists systemctl status systemd-tmpfiles-setup.service ● systemd-tmpfiles-setup.service - Create Volatile Files and Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static) Active: active (exited) since Fri 2020-08-21 15:03:05 CEST; 14min ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Process: 802 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=73) Main PID: 802 (code=exited, status=73) CPU: 8ms août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /var during canonicalization of /var/log/journal/787a3b2dc6e04b65a942e031f016b105. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /var during canonicalization of /var/log/journal/787a3b2dc6e04b65a942e031f016b105. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /var during canonicalization of /var/log/journal/787a3b2dc6e04b65a942e031f016b105. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /sys during canonicalization of /sys/module/kernel/parameters. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /run during canonicalization of /run/log/journal. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /run during canonicalization of /run/log/journal. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /var during canonicalization of /var/log/journal/787a3b2dc6e04b65a942e031f016b105/system.journal. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /var during canonicalization of /var/log/journal/787a3b2dc6e04b65a942e031f016b105/system.journal. août 21 15:03:05 PC-JOHN systemd-tmpfiles[802]: Detected unsafe path transition / → /var during canonicalization of /var/lib/tpm2-tss/system/keystore. Are all those messages the source of the problem?
I suspect 'mysql_update' is too long ago to be relevant; 10.3.9 was 2y ago. > /run/mysqld does not exist seems to matter. It does for Dave & myself: $ ls -l /run | grep mysql drwxr-xr-x 2 mysql mysql 40 Aws 21 19:14 mysqld/ > Are all those messages the source of the problem? Possibly. Assigning this to Marc for 'mariadb' in the hope of an explanation.
CC: lewyssmith => (none)Assignee: bugsquad => mageia
It's definitly a trouble with systemd-tmpfiles-setup, this morning I have the same problem with dhcpd and named who didn't start because of the lack of both/run/dhcpd and /run/named
Find out that a guy using ubuntu had the same problem, I applied his solution: chown root:root / And it works! systemctl status systemd-tmpfiles-setup.service return no error Systemctl status mysqld.service return active(running) Have now to findout when and why / has changed of owner!
found that thread describing the problem: https://github.com/systemd/systemd/issues/11282 all works on my vbox image, but not in chrooted environment; but this might be, because systemd totally refuses to start programs in chrooted environment
Are you using systemd-nspawn or chroot? In a systemd distro like Mageia, systemd-nspawn should normally be used, not chroot. Would have helped to know at the start of this report that this was in a virtual install.
My install is not a virtual one. I don't know what is systemd-nspawn, the program is here on my system but if it is used it's by default, never by me. I don't use a chroot except maybe for standard installation of named which I believe is the default. But maybe one thing of importance is to be known my root file system is btrfs.
@Dave only my install is chrooted; never heard of systemd-nspawn - I hate that systemd is changing everything that worked for decades.
systemd-nspawn is similar to chroot. See it's man page for differences between it and chroot. Some things only work in a chroot environment, while some others only work in a systemd-nspawn environment. I don't remember which work in which off hand. The question of how / become owned by other then root remains open, but unless that can be recreated, closing the bug as worksforme. Please reopen if you manage to recreate it.
Status: UNCONFIRMED => RESOLVEDResolution: (none) => WORKSFORME