Cannot run MySQL - no subdirectory .../mysqld

qajaq · 08-26-2019, 09:09 PM

I recently installed Lubuntu 19.04, after using Kubuntu for about 10 years. It's mostly working okay, but I cannot get MySQL to work.

I initially tried installing the full LAMP server with the tasksel utility, but ran into an error in the MySQL installation. I then tried using

Code:

apt-get remove mysql-server mysql-client
apt-get purge mysql-server mysql-client
apt-get install mysql-server mysql-client

but ran into the same error.

Several days later, I installed another software package using the Muon utility, and after Muon had done what I asked, it went on to install MySQL--and succeeded.

I was able to open MySQl as root and create a new user for myself. However, I have always kept my data files in a different location (in order to simplify my daily data backups). When I edited the /etc/mysql/mysql.conf.d/mysqld.cnf file to point to the new datadir, then edited /etc/apparmor.d/tunables to point the alias to the new datadir, the MySQL became unusable.

I get the following error message:

Code:

Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

On examination, I find that the subdirectory /var/run/mysqld does not exist. I can create it, set its owner:group to mysql: root and change permissions to 777 (rwxrwxrwx), but I still get the same response when I try to run MySQL. And when I look at the /var/run/ directory listing, I find that the .../mysqld/ subdirectory I created has been deleted.

Any ideas where I should look for a solution to allow MySQL to run?

scasey · 08-26-2019, 09:16 PM

If there's no mysqld.sock, then mysqld is not running.
That file is created when the daemon (mysqld) is running. You don't (and shouldn't) create it yourself.

I don't know if Lubuntu is SysV or systemd, so can't help you with starting the daemon...
but that's the problem: mysqld is not running, so you can't connect to it.

qajaq · 08-26-2019, 10:53 PM

According to the table on Distrowatch.com, Lubuntu uses systemd.
Does that tell you where you might point me, to learn more about the failure of mysqld to run?

scasey · 08-26-2019, 11:18 PM

Quote:

Originally Posted by qajaq

According to the table on Distrowatch.com, Lubuntu uses systemd.
Does that tell you where you might point me, to learn more about the failure of mysqld to run?

Try

Code:

systemctl enable mysqld.service
systemctl start mysqld.service

The enable sets it up to start at boot...the start, well, starts it.

See man systemctl

Let us know.

qajaq · 08-27-2019, 09:01 AM

I ran the first command and got the following result:

Code:

root: $ systemctl enable mysqld.service
Failed to enable unit: Unit file mysqld.service does not exist.

Thanks for the tip on man systemctl - A good source of further education for me.

Steve R. · 08-27-2019, 01:06 PM

I recently re-installed mariadb unto Mint19.2. As a personal preference, I avoid using LAMP. I also experimented with Lubuntu for a short period of time and found it to be deficient. But that is just a personal observation.

You may want to take a look at: Install phpMyadmin, Apache2 and PHP 7.3 on Ubuntu.

scasey · 08-27-2019, 03:31 PM

Quote:

Originally Posted by qajaq

I ran the first command and got the following result:

Code:

root: $ systemctl enable mysqld.service
Failed to enable unit: Unit file mysqld.service does not exist.

Have you installed mysqld? You've only posted about installing the client.

What does

Code:

systemctl | grep mysql

return?

qajaq · 08-27-2019, 04:03 PM

My installation line was

Code:

apt-get install mysql-server mysql-client

That's all I've needed in the past. And MySQL did work for me before I tried changing the data directory in the config and apparmor files.

Code:

systemctl | grep msyql
mysql.service     loaded failed failed MySQL Community Server

scasey · 08-27-2019, 07:25 PM

Quote:

Originally Posted by qajaq

My installation line was

Code:

apt-get install mysql-server mysql-client

That's all I've needed in the past. And MySQL did work for me before I tried changing the data directory in the config and apparmor files.

Code:

systemctl | grep msyql
mysql.service     loaded failed failed MySQL Community Server

aha!

Code:

systemctl status mysql

(you really need to learn about systemd/systemctl)

qajaq · 08-27-2019, 08:33 PM

I'm quickly becoming a true believer, in re: systemd and systemctl.

Running the command you suggested, I get:

Code:

● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-08-27 20:35:39 EDT; 29min ago
  Process: 17923 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
  Process: 17932 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/run/mysqld/mysqld.pid (code=exited, status=1/FAILURE)

Aug 27 20:35:39 Atlantis systemd[1]: mysql.service: Service RestartSec=100ms expired, scheduling restart.
Aug 27 20:35:39 Atlantis systemd[1]: mysql.service: Scheduled restart job, restart counter is at 5.
Aug 27 20:35:39 Atlantis systemd[1]: Stopped MySQL Community Server.
Aug 27 20:35:39 Atlantis systemd[1]: mysql.service: Start request repeated too quickly.
Aug 27 20:35:39 Atlantis systemd[1]: mysql.service: Failed with result 'exit-code'.
Aug 27 20:35:39 Atlantis systemd[1]: Failed to start MySQL Community Server.

That didn't see particularly informative, though I may be missing something important. However, back when I first tried the old routine to change my data directory, the last step was to invoke

Code:

service mysql start

and when I did that, I was directed to explore both

Code:

systemctl status mysql.service

(which showed me much the same information as I list above) and

Code:

journalctl -xe

which initially didn't seem much more informative until I learned that it displays its results much like the less utility. When I scrolled up, I found a line that looks a bit suspicious:

Code:

Aug 27 20:00:17 Atlantis audit[16764]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=16764 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

There are a few more lines with very similar information. The 'requested_mask="r"' and 'denied_mask="r"' caught my attention.

scasey · 08-27-2019, 08:52 PM

OK. You're on the right track, I think.
I don't know what, exactly, is the problem, 'tho, except to point out that mysqld

Quote:

did work for me before I tried changing the data directory in the config and apparmor files

so maybe undo those changes first...

What did you change there, and why?

Bottom line: mysql doesn't work because mysqld isn't running. That's the first problem to solve.

What does the mysqld.log say, if you have one?

qajaq · 08-28-2019, 12:27 PM

I undid all the changes, restarted apparmor, and started MySQL -- and I have MySQL back again. I thought I'd tried this approach before, but the difference this time is that instead of commenting-out my changes and un-commenting the original configuration lines (as I had done before), I actually deleted the changes and reinstated the originals.

Here's what I had changed (and, now, un-changed):
In /etc/mysql/mysql.conf.d/mysqld.cnf

Code:

# datadir = /var/lib/mysql
datadir = /libdata/mysql

In /etc/apparmor.d/tunables/alias I added the line:

Code:

alias /var/lib/mysql/ -> /libdata/mysql/,

Then I issued the following commands:

Code:

systemctl restart apparmor
service mysql start

I made those changes because I have a large, separate partition on which I mount my /libdata directory in which to store all my data (documents, spreadsheets, drawings, DTP files, etc., as well as MySQL database files) so that my daily back-up cron-job can do its job simply, and so that when I upgrade to a new LTS version of the OS, all my data is safely apart from whatever the OS-installer wants to fiddle with.

And, BTW, I found no mysqld.log anywhere on the HDD.