Start scanner daemon saned on Fedora Server 31 using systemd - fedora

I am trying to start saned using systemd on Fedora Server 31 arm7hl.
My systemd units look like:
saned.socket:
[Unit]
Description=saned incoming socket
PartOf=saned.service
[Socket]
ListenStream=6566
Accept=yes
MaxConnections=5
[Install]
WantedBy=sockets.target
saned.service:
[Unit]
Description=Scanner Service
Requires=saned.socket
[Service]
ExecStart=/usr/sbin/saned
User=saned
Group=saned
StandardInput=socket
#StandardOutput=syslog
StandardError=syslog
Environment=SANE_CONFIG_DIR=/etc/sane.d
Environment=SANE_DEBUG_DLL=128 SANE_DEBUG_NET=128
[Install]
Also=saned.socket
but when I want to start saned.service, I always get
Mar 14 11:00:32 host systemd[1]: saned.service: Got no socket.
Mar 14 11:00:32 host systemd[1]: saned.service: Failed to run 'start' task: Invalid argument
Mar 14 11:00:32 host systemd[1]: saned.service: Failed with result 'resources'.
Any ideas what could be wrong?
Best regards,
rforberger

Ok, I solved it myself.
I followed the instructions of the man page of saned, where an example of the systemd units is described.
Now my saned unit is still in dead state (systemd) but I can scan remotely anyway....

Related

slurmd.service is Failed & there is no PID file /var/run/slurmd.pid

I am trying to start slurmd.service using below commands but it is not successful permanently. I will be grateful if you could help me to resolve this issue!
systemctl start slurmd
scontrol update nodename=fwb-lab-tesla1 state=idle
This is the status of slurmd.service
cat /usr/lib/systemd/system/slurmd.service
[Unit]
Description=Slurm node daemon
After=network.target munge.service
ConditionPathExists=/etc/slurm/slurm.conf
[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/slurmd
ExecStart=/usr/sbin/slurmd $SLURMD_OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/var/run/slurmd.pid
KillMode=process
LimitNOFILE=51200
LimitMEMLOCK=infinity
LimitSTACK=infinity
[Install]
WantedBy=multi-user.target
and this the status of the node:
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
gpucompute* up infinite 1 drain fwb-lab-tesla1
$ sinfo -R
REASON USER TIMESTAMP NODELIST
Low RealMemory root 2020-09-28T16:46:28 fwb-lab-tesla1
$ sinfo -Nl
Thu Oct 1 14:00:10 2020
NODELIST NODES PARTITION STATE CPUS S:C:T MEMORY TMP_DISK WEIGHT AVAIL_FE REASON
fwb-lab-tesla1 1 gpucompute* drained 32 32:1:1 64000 0 1 (null) Low RealMemory
Here there is the contents of slurm.conf
$ cat /etc/slurm/slurm.conf
# slurm.conf file generated by configurator easy.html.
# Put this file on all nodes of your cluster.
# See the slurm.conf man page for more information.
#
ControlMachine=FWB-Lab-Tesla
#ControlAddr=137.72.38.102
#
MailProg=/bin/mail
MpiDefault=none
#MpiParams=ports=#-#
ProctrackType=proctrack/cgroup
ReturnToService=1
SlurmctldPidFile=/var/run/slurmctld.pid
#SlurmctldPort=6817
SlurmdPidFile=/var/run/slurmd.pid
#SlurmdPort=6818
SlurmdSpoolDir=/var/spool/slurmd
#SlurmUser=slurm
SlurmdUser=root
StateSaveLocation=/var/spool/slurm/StateSave
SwitchType=switch/none
TaskPlugin=task/cgroup
#
#
# TIMERS
#KillWait=30
#MinJobAge=300
#SlurmctldTimeout=120
#SlurmdTimeout=300
#
#
# SCHEDULING
FastSchedule=1
SchedulerType=sched/backfill
SelectType=select/cons_res
SelectTypeParameters=CR_CPU_Memory
# Prevent very long time waits for mix serial/parallel in multi node environment
SchedulerParameters=pack_serial_at_end
#
#
# LOGGING AND ACCOUNTING
AccountingStorageType=accounting_storage/filetxt
# Need slurmdbd for gres functionality
#AccountingStorageTRES=CPU,Mem,gres/gpu,gres/gpu:Titan
ClusterName=cluster
#JobAcctGatherFrequency=30
JobAcctGatherType=jobacct_gather/linux
#SlurmctldDebug=3
SlurmctldLogFile=/var/log/slurm/slurmctld.log
#SlurmdDebug=3
SlurmdLogFile=/var/log/slurm/slurmd.log
#
#
# COMPUTE NODES
GresTypes=gpu
#NodeName=fwb-lab-tesla[1-32] Gres=gpu:4 RealMemory=64000 Sockets=2 CoresPerSocket=8 ThreadsPerCore=2 State=UNKNOWN
#PartitionName=compute Nodes=fwb-lab-tesla[1-32] Default=YES MaxTime=INFINITE State=UP
#NodeName=fwb-lab-tesla1 NodeAddr=137.73.38.102 Gres=gpu:4 RealMemory=64000 Sockets=2 CoresPerSocket=8 ThreadsPerCore=2 State=UNKNOWN
NodeName=fwb-lab-tesla1 NodeAddr=137.73.38.102 Gres=gpu:4 RealMemory=64000 CPUs=32 State=UNKNOWN
PartitionName=gpucompute Nodes=fwb-lab-tesla1 Default=YES MaxTime=INFINITE State=UP
There is not any slurmd.pid in the below path. Just once by starting system it appears here but it is gone after few minutes again.
$ ls /var/run/
abrt cryptsetup gdm lvm openvpn-server slurmctld.pid tuned
alsactl.pid cups gssproxy.pid lvmetad.pid plymouth sm-notify.pid udev
atd.pid dbus gssproxy.sock mariadb ppp spice-vdagentd user
auditd.pid dhclient-eno2.pid httpd mdadm rpcbind sshd.pid utmp
avahi-daemon dhclient.pid initramfs media rpcbind.sock sudo vpnc
certmonger dmeventd-client ipmievd.pid mount samba svnserve xl2tpd
chrony dmeventd-server lightdm munge screen sysconfig xrdp
console ebtables.lock lock netreport sepermit syslogd.pid xtables.lock
crond.pid faillock log NetworkManager setrans systemd
cron.reboot firewalld lsm openvpn-client setroubleshoot tmpfiles.d
[shirin#FWB-Lab-Tesla Seq2KMR33]$ systemctl status slurmctld
â slurmctld.service - Slurm controller daemon
Loaded: loaded (/usr/lib/systemd/system/slurmctld.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2020-09-28 15:41:25 BST; 2 days ago
Main PID: 1492 (slurmctld)
CGroup: /system.slice/slurmctld.service
ââ1492 /usr/sbin/slurmctld
Sep 28 15:41:25 FWB-Lab-Tesla systemd[1]: Starting Slurm controller daemon...
Sep 28 15:41:25 FWB-Lab-Tesla systemd[1]: Started Slurm controller daemon.
I try to start the service slurmd.service but it returns to failed after few minutes again
$ systemctl status slurmd
â slurmd.service - Slurm node daemon
Loaded: loaded (/usr/lib/systemd/system/slurmd.service; enabled; vendor preset: disabled)
Active: failed (Result: timeout) since Tue 2020-09-29 18:11:25 BST; 1 day 19h ago
Process: 25650 ExecStart=/usr/sbin/slurmd $SLURMD_OPTIONS (code=exited, status=0/SUCCESS)
CGroup: /system.slice/slurmd.service
ââ2986 /usr/sbin/slurmd
Sep 29 18:09:55 FWB-Lab-Tesla systemd[1]: Starting Slurm node daemon...
Sep 29 18:09:55 FWB-Lab-Tesla systemd[1]: Can't open PID file /var/run/slurmd.pid (yet?) after start: No ...ctory
Sep 29 18:11:25 FWB-Lab-Tesla systemd[1]: slurmd.service start operation timed out. Terminating.
Sep 29 18:11:25 FWB-Lab-Tesla systemd[1]: Failed to start Slurm node daemon.
Sep 29 18:11:25 FWB-Lab-Tesla systemd[1]: Unit slurmd.service entered failed state.
Sep 29 18:11:25 FWB-Lab-Tesla systemd[1]: slurmd.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
Log output of starting slurmd:
[2020-09-29T18:09:55.074] Message aggregation disabled
[2020-09-29T18:09:55.075] gpu device number 0(/dev/nvidia0):c 195:0 rwm
[2020-09-29T18:09:55.075] gpu device number 1(/dev/nvidia1):c 195:1 rwm
[2020-09-29T18:09:55.075] gpu device number 2(/dev/nvidia2):c 195:2 rwm
[2020-09-29T18:09:55.075] gpu device number 3(/dev/nvidia3):c 195:3 rwm
[2020-09-29T18:09:55.095] slurmd version 17.11.7 started
[2020-09-29T18:09:55.096] error: Error binding slurm stream socket: Address already in use
[2020-09-29T18:09:55.096] error: Unable to bind listen port (*:6818): Address already in use```
The log files states that it cannot bind to the standard slurmd port 6818, because there is something else using this address already.
Do you have another slurmd running on this node? Or something else listening there? Try netstat -tulpen | grep 6818 to see what is using the address.

gunicorn daemon (active: failed) / curl(56) Recv Failure: Connection reset by peer

First thing, I am not sure if this is better here or on ask ubuntu (ubuntu did not have a 'gunicorn' tag so I think i'm in the right place). If it is not appropriate here just drop it in the comments and I'll close it.
I am following a digitalocean tutorial on deployment(https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-18-04).I am up to gunicorn set up. I'm at my wits end trying to get this gunicorn to work, so I have come here. Anything in quotes is the name of the current section in the article. I got up to "Checking for the Gunicorn Socket File" and "check for the existence of the gunicorn.sock file within the /run directory:" before failure.
Check for socket file:
sudo systemctl status gunicorn.socket returns
Failed to dump process list, ignoring: No such file or directory
● gunicorn.socket - gunicorn socket
Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor pres
Active: active (listening) since Fri 2020-02-21 21:34:06 UTC; 1min 8s ago
Listen: /run/gunicorn.sock (Stream)
CGroup: /system.slice/gunicorn.socket
Check for existence of gunicorn.sock:
file /run/gunicorn.sock
output: /run/gunicorn.sock: socket
Upon "Testing socket activation", it fails:
sudo systemctl status gunicorn
output:
● gunicorn.service - gunicorn daemon
Loaded: loaded (/etc/systemd/system/gunicorn.service;
Active: failed (Result: exit-code) since Fri 2020-02-
Main PID: 15708 (code=exited, status=217/USER)
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[1]: S
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[15708
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[15708
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[1]: g
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[1]: g
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[1]: g
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[1]: g
Feb 21 21:32:39 ubuntu-s-1vcpu-1gb-nyc3-01 systemd[1]: F
lines 1-13/13 (END)
It says to test socket activation, do the following:
curl --unix-socket /run/gunicorn.sock localhost
output(says I should see HTML):
curl: (56) Recv failure: Connection reset by peer
Not sure if I provided enough info. Below I will include my gunicorn.socket and gunicorn.service files as well as the layout of directories on my server.
gunicorn.socket:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
gunicorn.service:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=justin
Group=www-data
WorkingDirectory=/home/justin/project
ExecStart=/home/justin/project/env/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
jobzumo.wsgi:application
[Install]
WantedBy=multi-user.target
Layout of server/project:
home/justin/project/
This project/ folder contains env(env/bin/gunicorn does exist), jobzumo(django project), manage.py and static.
The only thing I am thinking is that I may have created these gunicorn files while using root and now I am trying to modify them using the user justin? Not really sure what is going on here. If I did not provide enough info or if you need me to run any type of debug commands please let me know. Thanks for any help.
I had the exact same propblem following this tutorial. OP's answer did not help in my case but I found a solution here. Maybe it helps others stubmling over this.
Many thanks to RussellMolimock for the following comment, which I found there!
"Go back into your virtualenv with source
[your_project_env]/bin/activate and enter which gunicorn That will
return the path to your gunicorn exectuable.
Paste that into the path section of the ‘ExecStart’ value inside the
’/etc/systemd/system/gunicorn.service’ file, and run the ‘sudo
systemctl daemon-reload’ and 'sudo systemctl restart gunicorn’
commands to restart your daemon and try curling again with curl
–unix-socket /run/gunicorn.sock localhost
I hope this helps!"
I had to run the following two commands:
sudo ufw delete allow 8000
sudo ufw allow 'Nginx Full'
and now everything is working. Apparently this opens my firewall up to port 80. Not sure why as I don't specify port 80 there, but it is working.
I faced this error because Gunicorn was not able to read the environment variables. This helped me in defining the environment variables for Gunicorn.
I deleted the whole project folder in Ubuntu (home/user/project) and restarted from the beginning, and it worked. I have tried multiple solutions on the Internet, restarting the daemon and changing the path of gunicorn, all fail.

Percona MySQL Server working but filling the messages log with errors

I have Percona MySQL server 5.7 running under CentOS 7 and although mysql is running without any noticeable errors, it is filling my /var/log/messages with the following every ten seconds:
Nov 15 10:07:27 server systemd: mysqld.service holdoff time over, scheduling restart.
Nov 15 10:07:27 server systemd: Starting MySQL Percona Server...
Nov 15 10:07:27 server mysqld_safe: 171115 10:07:27 mysqld_safe Adding '/usr/lib64/libjemalloc.so.1' to LD_PRELOAD for mysqld
Nov 15 10:07:27 server mysqld_safe: 171115 10:07:27 mysqld_safe Logging to '/var/lib/mysql/server.local.err'.
Nov 15 10:07:27 server mysqld_safe: 171115 10:07:27 mysqld_safe A mysqld process already exists
Nov 15 10:07:27 server systemd: mysqld.service: main process exited, code=exited, status=1/FAILURE
Nov 15 10:07:28 server systemd: Failed to start MySQL Percona Server.
Nov 15 10:07:28 server systemd: Unit mysqld.service entered failed state.
Nov 15 10:07:28 server systemd: Triggering OnFailure= dependencies of mysqld.service.
Nov 15 10:07:28 server systemd: mysqld.service failed.
Nov 15 10:07:28 server systemd: Started Service Status Monitor.
Nov 15 10:07:28 server systemd: Starting Service Status Monitor...
Even though it's stating in there that it failed to start the Percona server, it appears to be working as my website is still doing mysql queries. I know very little about mysql admin and was hoping a mysql guru could shed some light on what is happening.
The clue is here: "A mysqld process already exists". It can't start mysqld because another mysqld process is already running, and using the same port. You need to kill that process before the one you tried to start can start.
Re your comment:
Since this is CentOS 7, I assume mysql.service is being called by systemd.
In my experience, if you start mysqld "ad hoc" without using systemd, then systemd has no idea that it's running, and tries to start mysqld on its own. Systemd also cannot shut down an instance of mysqld unless it started that instance.
the mysqld process is active,ps -ef |grep mysqld ,kill -9 {}

How can I reinstate a MariaDB server process that is simply no longer running?

For a particular project I wanted to have Mint (Sonja) appliance with all MariaDB and only MariaDB doing MySQL's work, without a hint of MySQL so I know I'm working with MariaDB.
The appliance is one where I've installed multiple open source projects that power their own website (Alfresco, Request Tracker, SuiteCRM, etc.), and all of them seem to have worked either with MariaDB, or just used Postgres without interesting difficulty, and up until I tried to create a new MariaDB database to add a clone of a specific Wordpress site, MariaDB worked predictably well with no headaches on the same system. Until now, where I can't seem to find a pulse.
The MariaDB troubleshooting page confirmed what I'd found in my investigations (in particular, a ps wwaux | grep mysql only turned up the grep process). The basic problem as I'd encountered it was when I tried to log in to create a database:
monk#toolchest ~ $ mysql -uroot -p
Enter password:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2 "No such file or directory")
I've never gotten involved with MySQL's or MariaDB's /etc configuration files, but I looked briefly. They appeared sane to my uneducated eye.
Neither an aptitude reinstall mariadb-server nor a service mysql start produce any changes so far as I could tell.
For service mysql start, I got:
# service mysql start
Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.
The details for systemctl status mysql.service were:
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2017-07-14 18:16:38 EEST; 1min 11s ago
Docs: man:systemd-sysv-generator(8)
Process: 5011 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
Jul 14 18:16:38 toolchest /etc/init.d/mysql[5479]: 0 processes alive and '/usr/bin/mysql
Jul 14 18:16:38 toolchest /etc/init.d/mysql[5479]: [61B blob data]
Jul 14 18:16:38 toolchest /etc/init.d/mysql[5479]: error: 'Can't connect to local MySQL
Jul 14 18:16:38 toolchest /etc/init.d/mysql[5479]: Check that mysqld is running and that
Jul 14 18:16:38 toolchest /etc/init.d/mysql[5479]:
Jul 14 18:16:38 toolchest mysql[5011]: ...fail!
Jul 14 18:16:38 toolchest systemd[1]: mysql.service: Control process exited, code=exited
Jul 14 18:16:38 toolchest systemd[1]: Failed to start LSB: Start and stop the mysql data
Jul 14 18:16:38 toolchest systemd[1]: mysql.service: Unit entered failed state.
Jul 14 18:16:38 toolchest systemd[1]: mysql.service: Failed with result 'exit-code'.
The recent (i.e. non-cronned) content of journalctl -xe ran:
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mysql.service has failed.
--
-- The result is failed.
Jul 14 18:16:38 toolchest systemd[1]: mysql.service: Unit entered failed state.
Jul 14 18:16:38 toolchest systemd[1]: mysql.service: Failed with result 'exit-code'.
/etc/mysql/mariadb.cnf and /etc/mysql/my.cnf both read (comments stripped):
[client-server]
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/
/etc/mysql/my.cnf.fallback dropps the latter !includedir. Commenting out the latter /etc/mysql/my.cnf to match the fallback file produced identical results.
I can edit my question to include more of /etc/mysql/*, but I wanted to ask. Error messages similar to the ERROR 2002 are to be found in questions like Can't connect to local MySQL server through socket '/var/mysql/mysql.sock' (38), but these appear to be MySQL rather than MariaDB, and I suspect this may be a MariaDB-specific fluke.

MySQL doesn't start at all

This is awsome yesterday I got the same error and I debugged it but today I don't remember what to do since I did it to fast.
When I'm doing:
service mysql start
I get this message:
Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.
For this reason I did:
systemctl status mysql.service
and get:
Apr 16 18:11:25 darphus.xen.prgmr.com systemd[1]: Unit mysql.service entered failed state.
Apr 16 18:11:26 darphus.xen.prgmr.com systemd[1]: mysql.service holdoff time over, scheduling restart.
Apr 16 18:11:26 darphus.xen.prgmr.com systemd[1]: Stopping MySQL Community Server...
Apr 16 18:11:26 darphus.xen.prgmr.com systemd[1]: Starting MySQL Community Server...
Apr 16 18:11:26 darphus.xen.prgmr.com systemd[1]: mysql.service start request repeated too quickly, refusing to start.
Apr 16 18:11:26 darphus.xen.prgmr.com systemd[1]: Failed to start MySQL Community Server.
Apr 16 18:11:26 darphus.xen.prgmr.com systemd[1]: Unit mysql.service entered fai
journalctl -xn give:
Logs begin at Sun 2017-04-16 17:58:44 UTC, end at Sun 2017-04-16 18:16:35 UTC
Apr 16 18:16:34 darphus.xen.prgmr.com postfix/pickup[938]: warning: 868F625E66:
Apr 16 18:16:34 darphus.xen.prgmr.com postfix/pickup[938]: 868F625E66: uid=0 fro
Apr 16 18:16:34 darphus.xen.prgmr.com postfix/proxymap[941]: warning: mysql:/etc
Apr 16 18:16:34 darphus.xen.prgmr.com postfix/cleanup[1361]: warning: proxy:mysq
Apr 16 18:16:34 darphus.xen.prgmr.com postfix/cleanup[1361]: warning: 868F625E66
Apr 16 18:16:35 darphus.xen.prgmr.com postfix/pickup[938]: warning: 8744E25E66:
Apr 16 18:16:35 darphus.xen.prgmr.com postfix/pickup[938]: 8744E25E66: uid=0 fro
Apr 16 18:16:35 darphus.xen.prgmr.com postfix/proxymap[941]: warning: mysql:/etc
Apr 16 18:16:35 darphus.xen.prgmr.com postfix/cleanup[1362]: warning: proxy:mysq
Apr 16 18:16:35 darphus.xen.prgmr.com postfix/cleanup[1362]: warning: 8744E25E66
I think a tryed all the trick on the internet and nothing work for today.
Please help me since All my website are down for this reason.
The answer by #Lotfio Lakehal will fix your issues but should be considered a last resort - you certainly wouldn't want to run this on a database that had data you require as it will remove all your configuration values in the process. A better way would be to find out what is causing the issue in your my.cnf and fix it. MySQL has this ability built in.
mysqld --help --verbose
The above command will simulate starting your mysql server. If it can't it will give an error message and a description of what is wrong with the config files.
For instance I set up a test config file with some invalid data and when I ran the above command I got the following:
error: Found option without preceding group in config file: /etc/mysql/my.cnf at line: 22
This allows me to easily go to the configuration file and remove or edit the offending configuration, hopefully, allowing you to fix the said config file without having to do a full reinstall of the server.
Just to clarify this is in no way a put down on this answer, the previous answer will fix 99% of all issues but should be considered a last resort. Ideally, you want to fix the issue and understand why it occurred so you don't make the same mistakes in the future.
Usually this problem appears when you try to change something in the /etc/mysql/my.cnf.
WARNING
The following solution will delete all your database data! Try other solutions first.
Reinstalling MySQL may solve the problem, but should only be used as a last resort! To reinstall:
sudo apt purge mysql-server mysql-common
sudo apt autoremove mysql-server mysql-common
and reinstall it again
sudo apt-get update
sudo apt-get install mysql-server
check this out:
https://askubuntu.com/questions/392438/mysql-job-failed-to-start
note : This solution will delete all your database data ! So be aware of what you are doing .
I had the same problem running on ubuntu 18.04 with mysql 5.7. The first thing that I did was to go to mysql error log, it should be in /var/log/mysql/error.log.
There I found the following line:
[ERROR] InnoDB: Cannot allocate memory for the buffer pool
So looked like a memory issue, I checked the syslog for mentions of MySQL:
grep mysql syslog
Which displayed this:
kernel: [21270406.665399] Out of memory: Kill process 9674 (mysqld) score 251 or sacrifice child
I checked that I had ‘spare memory’ in the form of swap.
free -m
Which displayed this:
total used free shared buff/cache available
Mem: 985 522 69 45 393 276
Swap: 0 0 0
This meant that we have to setup swap space:
Swap: 0 0 0
In my case, mysql is on DigitalOcean and their guides are great so I defer you to the following:
How To Add Swap Space on Ubuntu 18.04
This answer should be read in conjunction with #"James Lendrem" answer.
If you changed or added anything to the mysql configuration files, try removing what you did.
First check the syslog file, which may give you a clue:
grep mysql /var/log/syslog | grep ERROR
This command searches the syslog for any reference to the term "mysql", and then limit those results to ones containing "ERROR".
Next look in the various config files. If you edited a specific config file, start there. Otherwise, look in all the config files in these directories:
ls -l /etc/mysql/*.cfg
ls -l /etc/mysql/mysql.conf.d/
ls -l /etc/mysql/conf.d/
If you change anything in any of the config files, (re)start the mysql server:
service mysql restart
# or else you could use for the first time:
service mysql start
I had the same problem running on ubuntu 18.04 with mysql 5.7
In log files I found the following lines:
Jul 13 01:25:35 r-lap audit[11196]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/node/" pid=11196 comm="mysqld" req
Jul 13 01:25:35 r-lap kernel: audit: type=1400 audit(1531425335.671:116): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/sys/devices/system/
On stopping apparmor, mysql start was successful with a message that ssl support could not be enabled. Stop the service.
To generate the certs,
Run
sudo mysql_ssl_rsa_setup --datadir /var/lib/mysql
The datadir may be different in your case.
Then do
sudo -i
cd /var/lib/mysql
chown mysql:mysql ./*
This will set the permissions for the generated cert and key files right.
Next you can start both apparmor and then mysql.
This fixed the issue in my case.
Since I did not try separately, I don't know whether it's the apparmor restart or generating the ssl key and certs that fixed the issue.
Note: I later found out this thread
For me, I ran some cache clearing operations to free up space using tools like Stacer, and then MySQL started showing problems.
Use this to get some clues first
grep mysql /var/log/syslog | grep ERROR
If the error says, Could not open file '/var/log/mysql/error.log' for error logging: No such file or directory
then clearly, the log files were cleaned up.
Use this to first create the MySQL directory and grant all permissions for MySQL to use that folder.
> sudo mkdir /var/log/mysql
> sudo chown -R mysql:mysql /var/log/mysql
> sudo service mysql restart
This solution has nothing to do with the my.cnf files and is completely safe on data.
Try running journalctl -u mysql.service to figure out why the error is happening.
Also, systemd cat mysql.service will show you the Service Unit file that describes your service - there might be errors.