I have just installed MariaDB 10.3 database server in Centos 7.
All went well, but when executing "systemctl status mariadb" command. This is the full output:
root#vps [/etc/init.d]# systemctl status mariadb
● mariadb.service - MariaDB 10.3.13 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: active (running) since Sun 2019-02-24 22:34:04 -03; 40min ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Main PID: 12247 (mysqld)
Status: "Taking your SQL requests now..."
CGroup: /system.slice/mariadb.service
└─12247 /usr/sbin/mysqld
Feb 24 22:46:39 vps.desytec.com mysqld[12247]: 2019-02-24 22:46:39 32 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch..._upgrade
Feb 24 22:46:39 vps.desytec.com mysqld[12247]: 2019-02-24 22:46:39 32 [ERROR] InnoDB: Column last_update in table `mysql`.`innodb_table_st...smatch).
Feb 24 22:46:39 vps.desytec.com mysqld[12247]: 2019-02-24 22:46:39 32 [ERROR] InnoDB: Fetch of persistent statistics requested for table `...instead.
Feb 24 22:46:40 vps.desytec.com mysqld[12247]: 2019-02-24 22:46:40 37 [ERROR] Column count of mysql.proc is wrong. Expected 21, found 20. ...is error
Feb 24 22:46:40 vps.desytec.com mysqld[12247]: 2019-02-24 22:46:40 37 [ERROR] Incorrect definition of table mysql.event: expected column '...TE','POS
Feb 24 22:46:41 vps.desytec.com mysqld[12247]: 2019-02-24 22:46:41 45 [ERROR] Incorrect definition of table mysql.event: expected column '...TE','POS
Feb 24 22:49:43 vps.desytec.com mysqld[12247]: 2019-02-24 22:49:43 47 [Warning] Access denied for user 'admin'#'localhost' (using password: YES)
Feb 24 22:49:43 vps.desytec.com mysqld[12247]: 2019-02-24 22:49:43 48 [Warning] Access denied for user 'admin'#'localhost' (using password: YES)
Feb 24 22:49:57 vps.desytec.com mysqld[12247]: 2019-02-24 22:49:57 55 [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch..._upgrade
Feb 24 22:49:57 vps.desytec.com mysqld[12247]: 2019-02-24 22:49:57 55 [ERROR] InnoDB: Column last_update in table `mysql`.`innodb_table_st...smatch).
Hint: Some lines were ellipsized, use -l to show in full.
Database is up, however, I want to solve the errors there. For example, problems with missing columns in tables or the access to admin#localhost user.
To try to solve the admin user problem, I have created that user and grant all privileges, but it is still showing that error.
Any help will be appreciated.
Looks as if there was a previous install already, running the mysql_upgrade tool should fix the system tables and bring them to the right structure for the version you have installed now.
https://mariadb.com/kb/en/library/mysql_upgrade/
Related
I am running Suricata in IDS (af-packet) mode on Ubuntu 20.04.5 LTS (Focal Fossa) and deployed as the root user:
NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 LTS"
VERSION_ID="20.04"
Following the Suricata "Adding your own Rules" Doc, I have added a very basic (for complexity ease when troubleshooting) alerting-rule with first available sid:1000000 from custom rules range:
########### Test Rules #############
alert ssh any any -> xxx.xxx.60.6 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000000;)
The .rules file for the local rules has sufficient permissions and matches suricata.rules, owned by root:
ls -halt /var/lib/suricata/rules/
total 22M
-rw-r--r-- 1 root root 3.2K Oct 17 00:00 classification.config
drwxr-x--- 2 root root 4.0K Oct 17 00:00 .
-rw-r--r-- 1 root root 22M Oct 17 00:00 suricata.rules
-rw-r--r-- 1 root root 210 Oct 13 21:45 local.rules
Ensured that the rules are added to Suricata suricata.yaml config and processed is restarted:
cat /etc/suricata/suricata.yaml | grep "rule-files" -A 5 -B 5
##
#default-rule-path: /var/lib/suricata/rules
default-rule-path: /etc/suricata/rules
rule-files:
- suricata.rules
- /var/lib/suricata/rules/local.rules
- /etc/suricata/rules/*.rules
AFAIK, the custom ruleset should be loaded into the suricata.rules file? Therefore, I am running the following verification subject to what I am reporting:
cat /var/lib/suricata/rules/suricata.rules | grep sid:1000000
I can test traffic and verify with tcpdump, matching the rule but never see a signature match in fast.log (which is logging other signature-matching traffic):
cat /var/log/suricata/fast.log | grep 1000000
I see no errors following statup of the service that would indicate an error present:
systemctl status suricata.service
● suricata.service - LSB: Next Generation IDS/IPS
Loaded: loaded (/etc/init.d/suricata; generated)
Active: active (running) since Mon 2022-10-17 13:11:39 UTC; 8h ago
Docs: man:systemd-sysv-generator(8)
Process: 2184275 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS)
Tasks: 78 (limit: 618963)
Memory: 25.2G
CGroup: /system.slice/suricata.service
└─2184295 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid --af-packet -D -v>
Oct 17 13:11:39 sec3 systemd[1]: Starting LSB: Next Generation IDS/IPS...
Oct 17 13:11:39 sec3 suricata[2184275]: Starting suricata in IDS (af-packet) mode... done.
Oct 17 13:11:39 sec3 systemd[1]: Started LSB: Next Generation IDS/IPS.
Can somebody help me with somewhere I may be silly here?
TYIA!
I'm trying to work through the manual installation guide. When I get as far as registering an admin account for the console (euare-accountcreate) or registering services (euserv-register-service) the eucalyptus-cloud service inconsistently crashes with the same JVM memory error. As an example a few times I've been able to register the UFS or create the admin account but when I move on to perform another step in the install it will fail and checking the service status shows that it has crashed. I don't have experience with Java memory errors and could really use some help understanding whats going on and how to investigate this type of error in general:
[root#cloud ~]# euserv-describe-services ufs-10.0.0.2
euserv-describe-services: error: connection error (('Connection
aborted.', BadStatusLine("''",)))
[root#cloud ~]# systemctl status eucalyptus-cloud -l
● eucalyptus-cloud.service - Eucalyptus cloud web services
Loaded: loaded (/usr/lib/systemd/system/eucalyptus-cloud.service;
enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2018-10-10 08:45:09 EDT;
4s ago
Process: 45951 ExecStart=/usr/sbin/eucalyptus-cloud $CLOUD_OPTS
(code=exited, status=1/FAILURE)
Main PID: 45951 (code=exited, status=1/FAILURE)
CGroup: /system.slice/eucalyptus-cloud.service
├─46206 /usr/bin/postgres -D /var/lib/eucalyptus/db/data -
h0.0.0.0 -p8777
├─46207 postgres: logger process
├─46209 postgres: checkpointer process
├─46210 postgres: writer process
├─46211 postgres: wal writer process
├─46212 postgres: autovacuum launcher process
└─46213 postgres: stats collector process
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: OpenJDK 64-Bit Server VM
warning: INFO: os::commit_memory(0x00007f496534b000, 12288, 0) failed;
error='Cannot allocate memory' (errno=12)
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: #
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: # There is insufficient
memory for the Java Runtime Environment to continue.
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: # Native memory
allocation (mmap) failed to map 12288 bytes for committing reserved
memory.
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: # An error report file
with more information is saved as:
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: #
/tmp/hs_err_pid45954.log
Oct 10 08:45:09 cloud eucalyptus-cloud[45951]: 2018-10-10 08:45:09
45951 ERROR 0574 Service exit with a return value of 1.
Oct 10 08:45:09 cloud systemd[1]: eucalyptus-cloud.service: main
process exited, code=exited, status=1/FAILURE
Oct 10 08:45:09 cloud systemd[1]: Unit eucalyptus-cloud.service
entered failed state.
Oct 10 08:45:09 cloud systemd[1]: eucalyptus-cloud.service failed.
Edit to include some version info:
[root#cloud ~]# cat /etc/centos-release
CentOS Linux release 7.5.1804 (Core)
[root#cloud ~]# java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
EDIT to note my point of confusion: This system only has 25G of RAM in use and 223G free. So I need help understanding how java is running out of memory.
try this fix:
echo 1999999 > /proc/sys/vm/max_map_count
I tried to install mariadb on blank Alpine Linux 3.6 in LXC container hosted on Turris OS (OpenWrt omnia 15.05 r47055).
Installation failed on permision denied error. I change privilegs but instalataror still failure.
root#alpinelxccontainer:~# DB_DATA_PATH="/var/lib/mysql"
root#alpinelxccontainer:~# DB_ROOT_PASS="heslo"
root#alpinelxccontainer:~# DB_USER="mariadb_user"
root#alpinelxccontainer:~# DB_PASS="heslo"
root#alpinelxccontainer:~# MAX_ALLOWED_PACKET="200M"
root#alpinelxccontainer:~# mysql_install_db --user=mysql --datadir=${DB_DATA_PATH}
WARNING: The host 'alpinelxccontainer' could not be looked up with /usr/bin/resolveip.
This probably means that your libc libraries are not 100 % compatible
with this binary MariaDB version. The MariaDB daemon, mysqld, should work
normally with the exception that host name resolving will not work.
This means that you should use IP addresses instead of hostnames
when specifying MariaDB privileges !
Installing MariaDB/MySQL system tables in '/var/lib/mysql' ...
2018-07-25 22:14:30 3069281488 [Note] /usr/bin/mysqld (mysqld 10.1.32-MariaDB) starting as process 1876 ...
2018-07-25 22:14:30 3069281488 [ERROR] mysqld: Can't create/write to file '/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied")
2018-07-25 22:14:30 3069281488 [ERROR] mysqld: Got error 'Can't create file' when trying to use aria control file '/var/lib/mysql/aria_log_control'
2018-07-25 22:14:30 3069281488 [ERROR] Plugin 'Aria' init function returned error.
2018-07-25 22:14:30 3069281488 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
2018-07-25 22:14:30 3069281488 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
2018-07-25 22:14:30 3069281488 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-07-25 22:14:30 3069281488 [Note] InnoDB: The InnoDB memory heap is disabled
2018-07-25 22:14:30 3069281488 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-07-25 22:14:30 3069281488 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2018-07-25 22:14:30 3069281488 [Note] InnoDB: Compressed tables use zlib 1.2.11
2018-07-25 22:14:30 3069281488 [Note] InnoDB: Using Linux native AIO
2018-07-25 22:14:30 3069281488 [Note] InnoDB: Using generic crc32 instructions
2018-07-25 22:14:30 3069281488 [ERROR] mysqld: Can't create/write to file '/tmp/ibXXXXXX' (Errcode: 13 "Permission denied")
2018-07-25 22:14:30 b6f184d0 InnoDB: Error: unable to create temporary file; errno: 13
2018-07-25 22:14:30 3069281488 [ERROR] Plugin 'InnoDB' init function returned error.
2018-07-25 22:14:30 3069281488 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2018-07-25 22:14:30 3069281488 [ERROR] Unknown/unsupported storage engine: InnoDB
2018-07-25 22:14:30 3069281488 [ERROR] Aborting
root#alpinelxccontainer:~# ls -la /var/lib/mysql/
total 0
drwxr-sr-x 1 mysql mysql 48 Jul 25 22:14 .
drwxr-xr-x 1 root root 36 Jul 25 22:09 ..
drwx------ 1 mysql mysql 0 Jul 25 22:14 mysql
-rw-rw---- 1 mysql mysql 0 Jul 25 22:14 mysql-bin.index
drwx------ 1 mysql mysql 0 Jul 25 22:14 test
root#alpinelxccontainer:~# chmod -R 777 /var/lib/mysql/
root#alpinelxccontainer:~# ls -la /var/lib/mysql/
total 0
drwxrwxrwx 1 mysql mysql 48 Jul 25 22:14 .
drwxr-xr-x 1 root root 36 Jul 25 22:09 ..
drwxrwxrwx 1 mysql mysql 0 Jul 25 22:14 mysql
-rwxrwxrwx 1 mysql mysql 0 Jul 25 22:14 mysql-bin.index
drwxrwxrwx 1 mysql mysql 0 Jul 25 22:14 test
root#alpinelxccontainer:~# mysql_install_db --user=mysql --datadir=${DB_DATA_PATH}
Still same error: [ERROR] mysqld: Can't create/write to file '/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied")
Complete dump of installation: https://gist.github.com/jakubs/24c642bc8d6779beaf1b944c6f399675
Related: installation guide: https://wiki.alpinelinux.org/wiki/MariaDB
This might be specific to openSUSE / systemd.
I'm having trouble mounting an encrypted loopback file using the procedure described on the SDB:Encrypted filesystems knowledge base. I get this behaviour:
[mjl#tesla:~]
[11:12] $ sudo systemctl start /home/mjl/key
Job for home-mjl-key.mount failed. See "systemctl status home-mjl-key.mount" and "journalctl -xe" for details.
[mjl#tesla:~]
[11:12] 1 $ sudo systemctl status home-mjl-key.mount
● home-mjl-key.mount - /home/mjl/key
Loaded: loaded (/etc/fstab; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since Sun 2018-03-11 11:12:41 AEDT; 3s ago
Where: /home/mjl/key
What: /home/mjl/.tomb
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 12949 ExecMount=/usr/bin/mount /home/mjl/.tomb /home/mjl/key -t crypt -o loop,user,acl,user_xattr (code=exited, status=32)
Mar 11 11:12:41 tesla systemd[1]: Mounting /home/mjl/key...
Mar 11 11:12:41 tesla mount[12949]: mount: unknown filesystem type 'crypt'
Mar 11 11:12:41 tesla systemd[1]: home-mjl-key.mount: Mount process exited, code=exited status=32
Mar 11 11:12:41 tesla systemd[1]: Failed to mount /home/mjl/key.
Mar 11 11:12:41 tesla systemd[1]: home-mjl-key.mount: Unit entered failed state.
[mjl#tesla:~]
[11:12] 3 $
The /home/mjl/.tomb loopback file was created using YaST Partitioner; I specified that I did not want it mounted at system start time, but that users should be allowed to mount it.
So it created the file, added an entry to /etc/cryptab and also this entry to /etc/fstab:
[mjl#tesla:~]
[11:12] 3 $ tail -n1 /etc/fstab
/home/mjl/.tomb /home/mjl/key crypt loop,user,noauto,acl,user_xattr,nofail 0 0
[mjl#tesla:~]
[11:15]$
There is the 'crypt' filesystem type.
My question is: how should I be mounting this as a user? Is systemd failing because of the filesystem type, or because I haven't told it the encryption key?
I've also tried mounting directly:
[mjl#tesla:~]
[11:16]$ sudo mount /home/mjl/key
mount: unknown filesystem type 'crypt'
[mjl#tesla:~]
The same error. So I guess I'm not mounting it correctly. Do I need to do something with cryptsetup
Going to my app produces a 502 gateway error. Found out that it was because my how_lit.service is failing. But I am having trouble finding out why.
Tried editing the application and the ini document. Cannot figure out whats wrong.
The Nginx and uWSGI services are up and running fine.
Service Status:
lit#digitalocean:~/howlit$ sudo service how_lit status
[sudo] password for lit:
● how_lit.service - uWSGI instance to serve how lit rest api
Loaded: loaded (/etc/systemd/system/how_lit.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2016-08-04 00:30:44 EDT; 5 days ago
Process: 14294 ExecStart=/home/lit/howlit/env/bin/uwsgi --ini /home/lit/howlit/howlit.ini (code=exited, status=1/FAILURE)
Main PID: 14294 (code=exited, status=1/FAILURE)
Aug 04 00:30:44 digitalocean systemd[1]: Started uWSGI instance to serve how lit rest api.
Aug 04 00:30:44 digitalocean uwsgi[14294]: [uWSGI] getting INI configuration from /home/lit/howlit/howlit.ini
Aug 04 00:30:44 digitalocean systemd[1]: how_lit.service: Main process exited, code=exited, status=1/FAILURE
Aug 04 00:30:44 digitalocean systemd[1]: how_lit.service: Unit entered failed state.
Aug 04 00:30:44 digitalocean systemd[1]: how_lit.service: Failed with result 'exit-code'.
Directory and Permissions:
lit#digitalocean:~/howlit$ ls -l .
total 16
drwx---r-x 6 lit www-data 4096 Jul 29 11:47 env
-rwx---r-x 1 lit www-data 202 Aug 3 23:29 howlit.ini
-rwx---r-x 1 lit www-data 1203 Aug 3 23:01 how_lit_restapi.py
-rwxr-xr-x 1 lit www-data 72 Aug 3 23:27 wsgi.py
/etc/systemd/system/how_lit.service:
lit#digitalocean:~/howlit$ cat /etc/systemd/system/how_lit.service
[Unit]
Description=uWSGI instance to serve how lit rest api
After=network.target
[Service]
User=lit
Group=www-data
WorkingDirectory=/home/lit/howlit/
Environment="PATH=/home/lit/howlit/env/bin"
ExecStart=/home/lit/howlit/env/bin/uwsgi --ini /home/lit/howlit/howlit.ini
[Install]
WantedBy=multi-user.target
howlit.ini file:
lit#digitalocean:~/howlit$ cat howlit.ini
[uwsgi]
module = wsgi:app
uid = lit
gid = www-data
master = true
processes = 5
socket = how_lit_restapi.sock
chmod-sock = 666
vacum = true
die-on-term = true
gto = /var/log/uwsgi/%n.log
Tried running it by hand:
lit#digitalocean:~/howlit$ /home/lit/howlit/env/bin/uwsgi --ini /home/lit/howlit/howlit.ini
[uWSGI] getting INI configuration from /home/lit/howlit/howlit.ini
*** Starting uWSGI 2.0.13.1 (64bit) on [Tue Aug 9 18:28:25 2016] ***
compiled with version: 5.4.0 20160609 on 29 July 2016 11:48:08
os: Linux-4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016
nodename: digitalocean
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/lit/howlit
detected binary path: /home/lit/howlit/env/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 1896
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
bind(): Permission denied [core/socket.c line 230]
permission error again?
SOLVED IT: By sending my socket into tmp, but still getting bad gateway error when I navigate to my site :(
Solved my own problem.
First I checked my services.
sudo service nginx status
sudo service uwsgi status
sudo service how_lit status
then I saw them all running and up but was still getting the bad gateway error. Well after checking the logs had no errors. I had to assume my configs.
Then I realized my mistake....I never restarted all of it, just certain parts at certain times. So I restarted every single one as such:
sudo service nginx restart
sudo service uwsgi restart
sudo service how_lit restart
now it works.
About the permission issue I tried it by putting the socket into the /tmp directory that way www-data group users can access it as well as root. I learned that you need to be able to create the socket and allow access to the system for it.
I moved it out of tmp btw later for production as I was told that was not best practice.