Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.1(EOL)
Description
That's the notorious problem with "inactive (dead)", I'm filing it to track upstream bugs further, and also hopefully to have a workaround by the next release.
It has been observed on Ubuntu Vivid, Debian Sid, Fedora 22.
Quoting my email from earlier:
sudo systemctl stop mariadb
|
|
# needs to be fast, do not sleep more than 1 sec
|
|
sudo systemctl start mariadb
|
|
# delay does not matter
|
|
sudo systemctl disable mariadb
|
|
# delay does not matter
|
|
sudo systemctl enable mariadb
|
|
# delay does not matter
|
|
sudo systemctl status mariadb
|
|
############################
|
|
Here the service starts showing the infamous
|
|
############################
|
|
● mariadb.service - MariaDB database server
|
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
|
Drop-In: /etc/systemd/system/mariadb.service.d
|
└─migrated-from-my.cnf-settings.conf
|
Active: inactive (dead) since Wed 2015-10-14 15:04:58 UTC; 58s ago
|
Main PID: 880 (mysqld)
|
Status: "Taking your SQL requests now..."
|
CGroup: /system.slice/mariadb.service
|
└─880 /usr/sbin/mysqld
|
|
############################
|
|
If I then shut down the MariaDB server, e.g. via the shutdown command (or just SIGTERM the process), I get
|
|
############################
|
|
Broadcast message from systemd-journald@ubuntu-vivid-amd64 (Wed 2015-10-14 15:14:18 UTC):
|
|
systemd[1]: Caught <ABRT>, dumped core as pid 960.
|
|
|
Broadcast message from systemd-journald@ubuntu-vivid-amd64 (Wed 2015-10-14 15:14:18 UTC):
|
|
systemd[1]: Freezing execution.
|
|
############################
|
|
systemd:
|
|
ii libpam-systemd:amd64 219-7ubuntu3 amd64 system and service manager - PAM module
|
ii libsystemd0:amd64 219-7ubuntu3 amd64 systemd utility library
|
ii systemd 219-7ubuntu3 amd64 system and service manager
|
ii systemd-sysv 219-7ubuntu3 amd64 system and service manager - SysV links
|
Unfortunately, it happens not only when a user stops/starts the server quickly, but also apparently when installation process does the same. My experiments above were performed when MariaDB was already installed, and the machine was rebooted; but it also happens right after installation, and then it's not necessary to stop/start server manually, the sequence is
- install server
- disable service
- enable service
- run status
=> observe the problem.
It means that a user has no control over the situation, which makes it more important.