There are multiple ways to go with this but using logs is the simplest way as there is no need of creating table inside mysql to log the root or user login with timestamp as mentioned in : http://www.fromdual.com/sites/default/files/logon_trigger_wp.pdf
I installed logtail and logcheck using yum, then wrote the following script and then created a cron job which runs this script:
#!/bin/sh
if [ -f foundadmin.txt ]
then
rm foundadmin.txt
fi
if [ -f send.txt ]
then
rm send.txt
fi
/usr/sbin/logtail2 -f /var/log/mysqld.log -o mysqld.log.offset | grep "root@localhost on using Socket" > foundadmin.txt
if [ -s foundadmin.txt ]
then
echo "Subject: MYSQLDB Admin Login on $(hostname)" > send.txt
cat foundadmin.txt >> send.txt
/bin/mailx -s "Subject: MySQLDB Admin Login on $(hostname)" myemail@com < send.txt
rm foundadmin.txt
rm send.txt
fi
exit 0
#
this is the cron job to make it run every minute:
This is run a cron job in a time interval and mail the admins to notify
- cd /opt/mysql-check ; ./mysql-notify-script.sh
Determine cause of failed MariaDB start on CentOS 7
We found the cause of the problem. It seems the Linux OOM killer is killing the service when the VM runs out of memory.
Aggravating circumstances include a VM provided by GoDaddy. The machine has 1 GB of RAM and no virtual memory. We cannot upgrade RAM and we cannot configure a swap file.
We attempted to tune the VM performance for Apache and PHP, including web server parameters and caches. Unfortunately none of us are experts in this area so we are not sure how effective the changes were. In fact, given the problem reoccurs our attempts seems to have failed.
We are going to provide a cron job that (1) restarts the service if it is not running; and (2) repairs the database on a restart. (2) is important because we see corrupt tables on occasion after a kill.
For those in a similar situation, here are the commands for CentOS7 and MySQL:
Here is the script:
# cat /etc/cron.hourly/1restart-mysql.cron
#!/usr/bin/env bash
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
RUNNING=$(systemctl status mariadb.service | grep -i -c "running")
if [[ "$RUNNING" -eq 0 ]]; then
systemctl restart mariadb.service
mysqlcheck --all-databases --auto-repair --user=XXX --password=YYY
fi
And:
# ls -Al /etc/cron.hourly
total 8
-rwxr-xr-x 1 root root 362 Apr 13 2018 0yum-hourly.cron
-rwxr-xr-x 1 root root 429 Oct 13 17:33 1restart-mysql.cron
And here is how we determined the cause. We missed it originally because our first step was to bounce the server to restore service. Later we would check dmesg
and it would be empty. We did not find this information in other logs.
# dmesg
[51000952.633919] Out of memory in UB 5299: OOM killed process 692 (mysqld) score 0 vm:1689248kB, rss:101160kB, swap:0kB
[51000954.240514] Out of memory in UB 5299: OOM killed process 18692 (httpd) score 0 vm:484768kB, rss:27528kB, swap:0kB
[51021879.542687] Out of memory in UB 5299: OOM killed process 20755 (mysqld) score 0 vm:1684804kB, rss:96828kB, swap:0kB
[51031927.106440] Out of memory in UB 5299: OOM killed process 26157 (mysqld) score 0 vm:1687764kB, rss:92504kB, swap:0kB
[51031927.991303] Out of memory in UB 5299: OOM killed process 27789 (httpd) score 0 vm:484616kB, rss:28828kB, swap:0kB
[51031928.375203] Out of memory in UB 5299: OOM killed process 27999 (httpd) score 0 vm:484596kB, rss:28632kB, swap:0kB
[51031928.851050] Out of memory in UB 5299: OOM killed process 27722 (httpd) score 0 vm:482796kB, rss:26124kB, swap:0kB
[51038506.759513] Out of memory in UB 5299: OOM killed process 28865 (mysqld) score 0 vm:1683916kB, rss:92152kB, swap:0kB
[51038508.175325] Out of memory in UB 5299: OOM killed process 30527 (mysqld) score 0 vm:680280kB, rss:69276kB, swap:0kB
[51047405.296807] Out of memory in UB 5299: OOM killed process 21185 (mysqld) score 0 vm:1682140kB, rss:95504kB, swap:0kB
[51047406.815046] Out of memory in UB 5299: OOM killed process 21994 (mysqld) score 0 vm:413284kB, rss:30480kB, swap:0kB
[51094257.662248] Out of memory in UB 5299: OOM killed process 2751 (mysqld) score 0 vm:1678112kB, rss:95196kB, swap:0kB
[51097918.747681] Out of memory in UB 5299: OOM killed process 3689 (mysqld) score 0 vm:1683916kB, rss:91052kB, swap:0kB
[51098957.885464] Out of memory in UB 5299: OOM killed process 4833 (mysqld) score 0 vm:1683620kB, rss:91232kB, swap:0kB
[51099129.993959] Out of memory in UB 5299: OOM killed process 13167 (mysqld) score 0 vm:1686284kB, rss:95464kB, swap:0kB
[51099131.831039] Out of memory in UB 5299: OOM killed process 13255 (httpd) score 0 vm:482484kB, rss:25508kB, swap:0kB
[51099132.017423] Out of memory in UB 5299: OOM killed process 13215 (httpd) score 0 vm:480240kB, rss:22188kB, swap:0kB
[51099132.211569] Out of memory in UB 5299: OOM killed process 13216 (httpd) score 0 vm:478200kB, rss:20832kB, swap:0kB
[51099132.390457] Out of memory in UB 5299: OOM killed process 13240 (httpd) score 0 vm:478040kB, rss:20900kB, swap:0kB
[51099132.505624] Out of memory in UB 5299: OOM killed process 13245 (httpd) score 0 vm:478036kB, rss:20404kB, swap:0kB
Best Answer
It sounds like you're new to Docker. You may want to spend some time reading through documentation and examples to get a better feel for how things work.
First, simply installing software doesn't necessarily make it run, and that is certainly the case with CentOS and other Red Hat variants. On a bare metal host, you would simply run
systemctl start mariadb
to start it, but this only works because on a regular system, the/sbin/init
component of systemd is started as part of the boot process.Inside a docker container, nothing is running by default. For example, if you were to run
ps -fe
on your host, you would probably see hundreds of running processes.If you were to run:
You would see:
Because of this, you can't start services using the normal mechanism. You will instead need to (a) start the service manually and (b) ensure that you have started it such that it will stay in the foreground (because a Docker container exits when the foreground process exits or puts itself into the background).
If you take a look at the official mariadb image, you will see that it ultimately just calls
mysqld
to start the service.It sounds like you want to start mariadb inside a container and then try interacting it from within the same container. While this isn't the normal way of working with docker, you could...
More typically, you would use a
Dockerfile
to build a mariadb image (or just use the official one), start it, and then usemysql
on your host or in another container to interact with that mariadb instance.