I need to change the read permissions from 640 to 644 so a different Linux user can access the MariaDB error log. My server's host uses CloudLinux and it is setup to use logrotate with the MariaDD error log. I'll mildly decent at find and grep and that is how I figured out it was logrotate` creating new files for each day. What the files look like in my FTP/SSH: - /var/log/mysql.error.log - /var/log/mysql.error.log-20250721 - /var/log/mysql.error.log-20250722 - /var/log/mysql.error.log-20250723 So logrotate has two files that I think are relevant however I've done the one obvious thing a day ago and after 24 hours passed the new log file was created using 640 permissions instead of 644: **/etc/logrotate.d/mariadb** > /var/lib/mysql/mysqld.log /var/lib/mysql/mariadb.log > /var/log/mariadb/*.log { > > \# Depends on a mysql@localhost unix_socket authenticated user with > RELOAD privilege su mysql mysql > > \# If any of the files listed above is missing, skip them silently > without # emitting any errors missingok > > \# If file exists but is empty, don't rotate it notifempty > > \# Run monthly monthly > > \# Keep 6 months of logs rotate 6 > > \# If file is growing too big, rotate immediately maxsize 500M > > \# If file size is too small, don't rotate at all minsize 50M > > \# Compress logs, as they are text and compression will save a lot of > disk space compress > > \# Don't compress the log immediately to avoid errors about "file > size changed while zipping" delaycompress > > \# Don't run the postrotate script for each file configured in this > file, but # run it only once if one or more files were rotated > sharedscripts > > \# After each rotation, run this custom script to flush the logs. > Note that # this assumes that the mariadb-admin command has database > access, which it # has thanks to the default use of Unix socket > authentication for the 'mysql' # (or root on Debian) account used > everywhere since MariaDB 10.4. postrotate > if test -r /etc/mysql/debian.cnf > then > EXTRAPARAM='--defaults-file=/etc/mysql/debian.cnf' > fi > > if test -x /usr/bin/mariadb-admin > then > /usr/bin/mariadb-admin $EXTRAPARAM --local flush-error-log \ > flush-engine-log flush-general-log flush-slow-log > fi endscript } **/etc/logrotate.d/mariadb** /var/log/mysql.error.log { create 644 mysql root notifempty daily rotate 5 missingok nocompress nocopytruncate dateext sharedscripts postrotate env HOME=/root/ /usr/bin/mysql -e 'flush logs' endscript So I changed the 640 to 644 in the **/etc/logrotate.d/mariadb** file and the file for the 23rd was still created using 640 permissions. **How do I force logrotate to create files using 644 permissions?** In the interim I looked up other examples and for some reason my file was missing the closing }, maybe that was the issue? However I'm not entirely sure, I'm only mildly versed in Linux and I don't want to wait 24 hours for *every* little thing to try or this will never get done!

*New note with important details* I just ran a few version tests and resulted in the following: Alright, here’s my latest update: - 10.5 works - 10.6 doesn’t - 10.7 works - 10.8 work - etc. I was hoping to use 10.6 since it is the LTS release…clearly there is something wrong with it though. I’m on the MariaDB slack channel at the moment, but for now I’ll revert to 10.5 from the MariaDB repo, since that has support for 2 years-ish. Am I missing something else? I didn't change anything but the MariaDB version and restarting the process. *Edit note for reference* Installing the EL Repo MariaDB 10.5 installs a package "mysql-selinux" and the default repo (epel-release?) allows the necessary communications and php-fpm can connect to mariadb fine. It seems like maybe the MariaDB repo package is missing this functionality. I would have installed the EL repo MariaDB on my AL 8.6 system, but removed it and went with the MariaDB repo for regular operation. I found the source for "mysql-selinux" here and it's not trivial like my "fix": https://github.com/devexp-db/mysql-selinux/blob/master/mysql.te this package is NOT installed on my 8.6 system which works... ***** I have a system running fine with SELinux enabled on AlmaLinux 8.6. I'm using stock AL 8.6 Apache/httpd (2.4.37 I think) and php from Remi's Repo: https://rpms.remirepo.net/wizard/ I initially installed MariaDB 10.4 directly from the MariaDB repo using these instructions: https://mariadb.com/resources/blog/how-to-install-mariadb-on-rhel8-centos8/ SELinux is enabled and I don't believe I made any customizations specifically for php-fpm to connect to the mysql.sock socket/process. I recently upgraded to MariaDB 10.6, again from the MariaDB repo, and everything continued working as it always did. For reference my "working" validation is using phpMyAdmin configured to connect through a local socket. I've installed my AlmaLinux 9 VM with stock Apache/httpd (2.4.51 I think). I installed MariaDB 10.6 from the same repo with the same instructions. Now, I'm getting a denial from SELinux for php-fpm (running as httpd_t) trying to connect to the /var/lib/mysql/mysql.sock process (running as unconfinsed_service_t). This denial prevents the connection and subsequent login from phpMyAdmin (running under the php-fpm service):

time->Mon Sep 26 22:14:07 2022
type=PROCTITLE msg=audit(1664244847.002:83): proctitle=7068702D66706D3A20706F6F6C20777777
type=SYSCALL msg=audit(1664244847.002:83): arch=c000003e syscall=42 success=no exit=-13 a0=5 a1=7ffc156c46b0 a2=1b a3=557032b785a0 items=0 ppid=706 pid=738 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="php-fpm" exe="/opt/remi/php74/root/usr/sbin/php-fpm" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1664244847.002:83): avc:  denied  { connectto } for  pid=738 comm="php-fpm" path="/var/lib/mysql/mysql.sock" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0

This ONLY shows up on my AL 9 install, AL 8.6 does not report this denial and allows the connection and subsequent login. I checked the file and process SELinux contexts and they are the same between 8.6 and 9. I've also tried different php-fpm versions, including the same between my 8.6 install and 9 (both php 7.4 from Remi). I've tried running the fpm pool under apache:apache and under my phpMyAdmin user with group apache. Any advice on how to track this down? I can "fix" the SELinux denial with the following policy, but it allows httpd to connect to any unconfined process:

module phpfpm_mariadb_socket 1.0;

require {
        type httpd_t;
        type unconfined_service_t;
        class unix_stream_socket connectto;
}

#============= httpd_t ==============
allow httpd_t unconfined_service_t:unix_stream_socket connectto;

I see two obvious differences: Apache 2.4.37 vs 2.4.51 (and potential related SELinux policy changes which I couldn't track down) and EL 8.6 vs EL 9 SELinux core changes (both had "latest" available updates applied). I copied the phpMyAdmin install from my 8.6 system into my 9 system, under the same usernames with the same permissions. I don't think that the php-fpm user:group configuration is relevant to the process contexts, or is it?

I'm trying to understand a significant discrepancy in disk usage between two MariaDB servers that are hosting the same application and (apparently) the same data. The two servers are entirely separate and unrelated. When I run df -h to check disk usage: Server 1: ~60G used Server 2: ~400G used To investigate further, I ran the following SQL query to check the size of each database: SELECT table_schema AS "Database", SUM(data_length + index_length) / 1024 / 1024 AS "Size (MB)" FROM information_schema.tables GROUP BY table_schema; Results: Server 1: | Database | Size (MB) | | -------- | -------------- | | information_schema| 0.20302000 | | mysql| 19.2345678| | performance_schema| 0.00000000| | myDB| 7153.45673428| | sys| 0.03561897| Server 2: | Database | Size (MB) | | -------- | -------------- | | information_schema| 0.20908965| | mysql| 21.45678765| | performance_schema| 0.00000000| | myDB| 8232.56789542| | sys| 0.03848632| As you can see, the actual data size is relatively close, yet the disk usage reported by df -h is vastly different. datadir in my.cnf points to the same location on both servers: /path/to/data Both servers are running the same MariaDB version (**11.4.2**) and have a similar setup. Running on a Red Hat 9.5 When I run SHOW variables LIKE 'log_bin%'; | Variable_name| Value | | -------- | -------------- | | log_bin| ON| | log_bin_basename| /path/to/data/mysqld-bin| | log_bin_compress| OFF| | log_bin_compress_min_len| 256| | log_bin_index| /path/to/binlog/log_bin.index| | log_bin_trust_function_creators| ON| When I run SHOW variables LIKE 'expire_logs_days%'; | Variable_name| Value | | -------- | -------------- | | expire_logs_days| 3.000000| and if I run ls -lhr /path/to/data/mysqld-bin* Engine used -> InnoDB If I run : du -ch /path/to/data/mysqld-bin* It gives me like 370G. I can see the most oldest files is 6 Mar. I think binlog files arn't properly purged. What else could be taking up disk space in /path/to/data that's not reflected in information_schema.tables? What should I check next to troubleshoot this?

I had to install MySQL Server community on our server (team lead did not want MariaDB due to support or something). Therefor I removed MariaDB which in turn also removed Postfix. Now I need to install Postfix because we need to relay emails. If I do a yum install postfix it also tries to install mariadb-libs, which conflicts with MySQL-Server. How can I install Postfix without using MariaDB? Or how can I solve this conflict? OS: RHEL 7.1 Some of the conflict error messages: Transaction check error: file /usr/share/mysql/charsets/README from install of mariadb-libs-1:5.5.41-2.el7_0.x86_64 conflicts with file from package MySQL-server-5.5.42-1.el7.x86_64 file /usr/share/mysql/charsets/Index.xml from install of mariadb-libs-1:5.5.41-2.el7_0.x86_64 conflicts with file from package MySQL-server-5.5.42-1.el7.x86_64 file /usr/share/mysql/charsets/armscii8.xml from install of mariadb-libs-1:5.5.41-2.el7_0.x86_64 conflicts with file from package MySQL-server-5.5.42-1.el7.x86_64 file /usr/share/mysql/charsets/ascii.xml from install of mariadb-libs-1:5.5.41-2.el7_0.x86_64 conflicts with file from package MySQL-server-5.5.42-1.el7.x86_64

In my CentOS Stream Linux 9 when I run the command: yum install perl-DBD-MySQL It gives me an error: Transaction Summary ================================================================================================================================================================================================================ Install 3 Packages Total size: 1.4 M Installed size: 7.3 M Is this ok [y/N]: y Downloading Packages: [SKIPPED] mysql-common-8.0.41-2.el9.x86_64.rpm: Already downloaded [SKIPPED] mysql-libs-8.0.41-2.el9.x86_64.rpm: Already downloaded [SKIPPED] perl-DBD-MySQL-4.053-1.el9.x86_64.rpm: Already downloaded Running transaction check Transaction check succeeded. Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'yum clean packages'. Error: Transaction test error: file /usr/share/mysql/charsets/Index.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/armscii8.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/ascii.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/cp1250.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/cp1251.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/cp1256.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/cp1257.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/cp850.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/cp852.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/cp866.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/dec8.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/geostd8.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/greek.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/hebrew.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/hp8.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/keybcs2.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/koi8r.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/koi8u.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/latin1.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/latin2.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/latin5.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/latin7.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/macce.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/macroman.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 file /usr/share/mysql/charsets/swe7.xml from install of mysql-common-8.0.41-2.el9.x86_64 conflicts with file from package MariaDB-common-10.6.22-1.el9.x86_64 I have done yum install perl-DBD-MySQL --enablerepo=* But got no luck! What else can I do? Thanks in advance!

When trying to start MariaDB with systemctl status mariadb, I get:

● mariadb.service - MariaDB 10.3.15 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since (date)
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/ 
  Process: 2512 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 2513 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=/usr/bin/galera_recovery; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 2521 ExecStart=/usr/bin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
 Main PID: 2521 (code=exited, status=1/FAILURE)
   Status: "Starting final batch to recover 13 pages from redo log"

[ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
[Note] Recovering after a crash using tc.log
[Note] Starting crash recovery...
[Note] Crash recovery finished.
[ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
[Note] Server socket created on IP: '::'.
[ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist
mariadb.service: Main process exited, code=exited, status=1/FAILURE
mariadb.service: Failed with result 'exit-code'.
Failed to start MariaDB 10.3.15 database server.

Having followed various tutorials, I may have made it worse. I cannot run mysql anymore (in the context of mysql < file.sql), since it says mysql: command not found. I have tried removing, reinstalling mariadb and rebooting my computer in between; but I'm out of luck. Any ideas? **EDIT:** Many others seem to be having this problem, . Not sure what else I did next as it has been over a year. I do know that following the installation guide [Arch Wiki](https://wiki.archlinux.org/index.php/MariaDB#Installation) page LINE BY LINE will guarantee a proper install. The formatting of the page made me read over things (important things were small, optional things were bold), but make sure you do that right and your installation should work.

My system has a broken MariaDb update going from 10.3 to 10.4. MariaDb does still work fine, but now I am having system upgrade issues. I have tried looking online for solutions but can't seem to find anything. Problem:

-shellsession
$ sudo apt-get upgrade               
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
  mariadb-server-10.3 : Depends: mariadb-client-10.3 (>= 1:10.3.28+maria~buster) but 1:10.3.27-0+deb10u1 is installed
  mariadb-server-core-10.3 : Breaks: mariadb-client-10.3 (< 1:10.3.28+maria~buster) but 1:10.3.27-0+deb10u1 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

While I try to fix-broken :

-shellsession
$ sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  libconfig-inifiles-perl libsnappy1v5
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  mariadb-client-10.3 mariadb-client-core-10.3
The following packages will be upgraded:
  mariadb-client-10.3 mariadb-client-core-10.3
2 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
6 not fully installed or removed.
Need to get 0 B/1,868 kB of archives.
After this operation, 19.6 MB disk space will be freed.
Do you want to continue? [Y/n] Y
Reading changelogs... Done
dpkg: regarding .../mariadb-client-core-10.3_1%3a10.3.28+maria~buster_amd64.deb containing mariadb-client-core-10.3:
 mariadb-client-10.3 conflicts with mysql-client-core-5.5
  mariadb-client-core-10.3 provides mysql-client-core-5.5 and is to be installed.

dpkg: error processing archive /var/cache/apt/archives/mariadb-client-core-10.3_1%3a10.3.28+maria~buster_amd64.deb (--unpack):
 conflicting packages - not installing mariadb-client-core-10.3
dpkg: regarding .../mariadb-client-10.3_1%3a10.3.28+maria~buster_amd64.deb containing mariadb-client-10.3:
 mariadb-client-core-10.3 conflicts with mysql-client-5.5
  mariadb-client-10.3 provides mysql-client-5.5 and is to be installed.

dpkg: error processing archive /var/cache/apt/archives/mariadb-client-10.3_1%3a10.3.28+maria~buster_amd64.deb (--unpack):
 conflicting packages - not installing mariadb-client-10.3
Errors were encountered while processing:
 /var/cache/apt/archives/mariadb-client-core-10.3_1%3a10.3.28+maria~buster_amd64.deb
 /var/cache/apt/archives/mariadb-client-10.3_1%3a10.3.28+maria~buster_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Are there multiple packages installed? Any ideas? ---------------- **Edit: adding more info** *Please edit your post to show the contents of your /etc/apt/sources.list:*

deb http://deb.debian.org/debian/  buster main
deb-src http://deb.debian.org/debian/  buster main

deb http://security.debian.org/debian-security  buster/updates main contrib
deb-src http://security.debian.org/debian-security  buster/updates main contrib

# buster-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/  buster-updates main contrib
deb [arch=arm64,ppc64el,amd64] http://mariadb.mirror.globo.tech/repo/10.3/debian  buster main
# deb-src [arch=arm64,ppc64el,amd64] http://mariadb.mirror.globo.tech/repo/10.3/debian  buster main
deb [arch=arm64,ppc64el,amd64] http://mariadb.mirror.globo.tech/repo/10.4/debian  buster main
# deb-src [arch=arm64,ppc64el,amd64] http://mariadb.mirror.globo.tech/repo/10.4/debian  buster main
deb-src http://deb.debian.org/debian/  buster-updates main contrib

*and any *.list files in /etc/apt/sources.list.d:*

ondrej-ubuntu-php-impish.list
php7.list

How to solve the issue below? $ sudo apt-get purge [sudo] password for massa: Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: libmariadbclient18 : Depends: libmysqlclient18 (= 10.0.28+maria-1~xenial) but it is not installed libstdc++-5-dev : Depends: libstdc++6 (>= 5.4.0-6ubuntu1~16.04.4) but 5.4.0-6ubuntu1~16.04.2 is installed libstdc++6 : Depends: gcc-5-base (= 5.4.0-6ubuntu1~16.04.2) but 5.4.0-6ubuntu1~16.04.4 is installed libstdc++6:i386 : Depends: gcc-5-base:i386 (= 5.4.0-6ubuntu1~16.04.2) but 5.4.0-6ubuntu1~16.04.4 is installed mariadb-server-10.0 : Depends: mariadb-client-10.0 (>= 10.0.28+maria-1~xenial) but 10.0.27-0ubuntu0.16.04.1 is installed E: Unmet dependencies. Try using -f.

Linux Mint 20 (Ubuntu 20). MariaDB version: "mariadb Ver 15.1 Distrib 10.7.3-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2" I want to run LibreOffice Base as the front end, using ODBC. I have tried to follow the MariaDB instructions here . I have put the file libmaodbc.so in /usr/lib64/. I believe this is the main connector file. I have made a file /etc/odbcinst.ini as follows: [MariaDB] Description=MariaDB Connector/ODBC v.3.0 Driver=/usr/lib64/libmaodbc.so UsageCount=1 and a file /etc/odbc.ini as follows: [localdb] Description = MariaDB connection to database Driver = MariaDB Database = localdb Server = localhost User = root Password = root Port = 3306 Socket = /var/run/mysqld/mysqld.sock When I try to connect using LO Base, this ODBC entry "localdb" is seen. But then when I test out the connection I get: "[unixODBC][Driver Manager]Data source name not found, and no default driver specified" "Data source name"? "default driver"? Anyone know what I should do? My theory is that the odbc.ini file references the odbcinst.ini file, which in turn drives the libmaodbc.so file. NB if I go as far as trying to actually make the connection, i.e. to get a list of tables in the database in LO Base, I get "The connection to the data source "xxx"* could not be established
[ma-3.1.15]Can't connect to local server through socket '/var/run/mysqld/mysqld.sock' (13)" \* i.e. the LO Base filename minus the ".odb" extension. And also to check my socket (with the MariaDB service running): mike@M17A:~/MariaDB_files$ netstat -ln | grep mysql unix 2 [ ACC ] STREAM LISTENING 263752 /var/run/mysqld/mysqld.sock ... interesting: seems to suggest that the socket is alive and well. Also I **can** connect using isql localdb from the CLI: doesn't this suggest things are set up OK?

The mysql.service got killed by the OOM killer. While investigating the root cause I wanted to change the unit configuration to restart if killed. I was surprised to find

Restart=on-abort

already in the default unit configuration file. Reading https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#Restart= I think when getting killed by OOM systemd should restart the service. Testing on a non production server with kill -9 pid shows the expected behavior, the service is automatically restarted. A simple systemctl restart mysql.service did work, so there should be nothing preventing systemd from bringing the service back up. So why is my service not restarted ? *Edit to anwser request in the comments* - The System is Debian 12 - mysql just symlinks to mariadb . But it is mariadb. - The unit file is the default delivered by the maintainers

# It's not recommended to modify this file in-place, because it will be
# overwritten during package upgrades.  If you want to customize, the
# best way is to create a file "/etc/systemd/system/mariadb.service",
# containing
#	.include /usr/lib/systemd/system/mariadb.service
#	...make your changes here...
# or create a file "/etc/systemd/system/mariadb.service.d/foo.conf",
# which doesn't need to include ".include" call and which will be parsed
# after the file mariadb.service itself is parsed.
#
# For more info about custom unit files, see systemd.unit(5) or
# https://mariadb.com/kb/en/mariadb/systemd/ 
#
# Copyright notice:
#
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.

[Unit]
Description=MariaDB 10.11.6 database server
Documentation=man:mariadbd(8)
Documentation=https://mariadb.com/kb/en/library/systemd/ 
After=network.target

[Install]
WantedBy=multi-user.target


[Service]

##############################################################################
## Core requirements
##

Type=notify

# Setting this to true can break replication and the Type=notify settings
# See also bind-address mariadbd option.
PrivateNetwork=false

##############################################################################
## Package maintainers
##

User=mysql
Group=mysql

# CAP_IPC_LOCK To allow memlock to be used as non-root user
# CAP_DAC_OVERRIDE To allow auth_pam_tool (which is SUID root) to read /etc/shadow when it's chmod 0
#   does nothing for non-root, not needed if /etc/shadow is u+r
# CAP_AUDIT_WRITE auth_pam_tool needs it on Debian for whatever reason
CapabilityBoundingSet=CAP_IPC_LOCK CAP_DAC_OVERRIDE CAP_AUDIT_WRITE

# PrivateDevices=true implies NoNewPrivileges=true and
# SUID auth_pam_tool suddenly doesn't do setuid anymore
PrivateDevices=false

# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full



# Doesn't yet work properly with SELinux enabled
# NoNewPrivileges=true

# Prevent accessing /home, /root and /run/user
ProtectHome=true

# Execute pre and post scripts as root, otherwise it does it as User=
PermissionsStartOnly=true

ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld

# Perform automatic wsrep recovery. When server is started without wsrep,
# galera_recovery simply returns an empty string. In any case, however,
# the script is not expected to return with a non-zero status.
# It is always safe to unset _WSREP_START_POSITION environment variable.
# Do not panic if galera_recovery script is not available. (MDEV-10538)
ExecStartPre=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
ExecStartPre=/bin/sh -c "[ ! -e /usr/bin/galera_recovery ] && VAR= || \
 VAR=cd /usr/bin/..; /usr/bin/galera_recovery; [ $? -eq 0 ] \
 && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1"

# Needed to create system tables etc.
# ExecStartPre=/usr/bin/mysql_install_db -u mysql

# Start main service
# MYSQLD_OPTS here is for users to set in /etc/systemd/system/mariadb.service.d/MY_SPECIAL.conf
# Use the [Service] section and Environment="MYSQLD_OPTS=...".
# This isn't a replacement for my.cnf.
# _WSREP_NEW_CLUSTER is for the exclusive use of the script galera_new_cluster
ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION

# Unset _WSREP_START_POSITION environment variable.
ExecStartPost=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"

ExecStartPost=/etc/mysql/debian-start

KillSignal=SIGTERM

# Don't want to see an automated SIGKILL ever
SendSIGKILL=no

# Restart crashed server only, on-failure would also restart, for example, when
# my.cnf contains unknown option
Restart=on-abort
RestartSec=5s

UMask=007

##############################################################################
## USERs can override
##
##
## by creating a file in /etc/systemd/system/mariadb.service.d/MY_SPECIAL.conf
## and adding/setting the following under [Service] will override this file's
## settings.

# Useful options not previously available in [mysqld_safe]

# Kernels like killing mariadbd when out of memory because its big.
# Lets temper that preference a little.
# OOMScoreAdjust=-600

# Explicitly start with high IO priority
# BlockIOWeight=1000

# If you don't use the /tmp directory for SELECT ... OUTFILE and
# LOAD DATA INFILE you can enable PrivateTmp=true for a little more security.
PrivateTmp=false

# Set an explicit Start and Stop timeout of 900 seconds (15 minutes!)
# this is the same value as used in SysV init scripts in the past
# Galera might need a longer timeout, check the KB if you want to change this:
# https://mariadb.com/kb/en/library/systemd/#configuring-the-systemd-service-timeout 
TimeoutStartSec=900
TimeoutStopSec=900

##
## Options previously available to be set via [mysqld_safe]
## that now needs to be set by systemd config files as mysqld_safe
## isn't executed.
##

# Number of files limit. previously [mysqld_safe] open-files-limit
LimitNOFILE=32768
# For liburing and io_uring_setup()
LimitMEMLOCK=524288
# Maximium core size. previously [mysqld_safe] core-file-size
# LimitCore=

# Nice priority. previously [mysqld_safe] nice
# Nice=-5

# Timezone. previously [mysqld_safe] timezone
# Environment="TZ=UTC"

# Library substitutions. previously [mysqld_safe] malloc-lib with explicit paths
# (in LD_LIBRARY_PATH) and library name (in LD_PRELOAD).
# Environment="LD_LIBRARY_PATH=/path1 /path2" "LD_PRELOAD=

# Flush caches. previously [mysqld_safe] flush-caches=1
# ExecStartPre=sync
# ExecStartPre=sysctl -q -w vm.drop_caches=3

# numa-interleave=1 equalivant
# Change ExecStart=numactl --interleave=all /usr/sbin/mariadbd......

# crash-script equalivent
# FailureAction=

I'm setting up a "clean" image for my home Raspberry pi running the latest Raspbian, and I'm finding a small problem when installing the mariadb database. So far, the steps I've taken are the following:

`
  sudo apt-get install -y mariadb-server

  sudo nano /etc/mysql/my.cnf

` Add the following lines to my.cnf:

`
  [mysqld]
  datadir=/mnt/RaspberryData/mysql
  socket=/mnt/RaspberryData/mysql/mysql.sock
  [client]
  port=3306
  socket=/mnt/RaspberryData/mysql/mysql.sock

` The path /mnt/RaspberryData/mysqlcontains the database info of my previous installation, which was configured through a hard link. This may or may not be the issue. Then execute:

`
  sudo sytemctl start mariadb
  journalctl -u mariadb

` And here's when I have the issue:

`
Jun 22 19:18:33 raspberrypi systemd: Starting MariaDB 10.3.22 database server...
Jun 22 19:18:34 raspberrypi mysqld: 2020-06-22 19:18:34 0 [Note] /usr/sbin/mysqld (mysqld 10.3.22-MariaDB-0+deb10u1) starting as process 2623 ...
Jun 22 19:18:35 raspberrypi systemd: Started MariaDB 10.3.22 database server.
Jun 22 19:18:35 raspberrypi /etc/mysql/debian-start: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jun 22 19:18:35 raspberrypi /etc/mysql/debian-start: Looking for 'mysql' as: /usr/bin/mysql
Jun 22 19:18:35 raspberrypi /etc/mysql/debian-start: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jun 22 19:18:35 raspberrypi /etc/mysql/debian-start: Version check failed. Got the following error when calling the 'mysql' command line client
Jun 22 19:18:35 raspberrypi /etc/mysql/debian-start: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Jun 22 19:18:35 raspberrypi /etc/mysql/debian-start: FATAL ERROR: Upgrade failed

` As you can see, there's some kind of update process that is trying to connect through a socket located in /var/run/mysqld/mysqld.sockbut that path has nothing (Only a mysqld.pid file). I'm guessing the guides on how to move the data from one location to another omitted some process or whatnot, as I can actually get into the database and execute queries. So, what am I missing here?

There are many servers in the network that I manage, and throughout that network, mysql is the standard and only "mysql-like" database used. (There's some postgre but that is another matter). Today, I wanted to install mysql on a new server (rPi running bookworm) and was surprised that "mysql-client" and "mysql-server" are no longer candidates for the platform. Instead, it seems we're supposed to use apt install default-mysql-client default-mysql-server So I did that, and mariadb was installed. (I quickly removed it and the other products installed with it.) I've tried to search how to force this to mysql rather than mariadb, to no avail. I checked /etc/alternatives and that does not seem to be the thing in my way. My research has led me only to comments like "Just use mariadb - it'll work." But there's apparently no refund when that proves incorrect. :| I know, mariadb is **meant to be** "almost completely" compatible with mysql. I don't need "almost" in this network. I need reliability and consistency. I'm sure the key word here is "**default**"-mysql (the key word should be mysql - call it what it is) but I could find no way to set my preferred **default**. How can I install mysql and not mariadb on Bookworm and any other variants that try to force us away from mysql? I get that there is SQL-level compatibility between Maria and MySql. But I'm more concerned about administration and what the NEXT change one or the other might make. Anyone with administrative experience will agree that maintaining two slightly dissimilar products is more than twice the effort from the standpoint that not only do you have to "know" both platforms, you also have to know the differences.

I'm in the process of setting up a singe-node Slurm workstation machine and I believe I followed the process closely and everything is working just fine. *See* below: **sudo systemctl restart slurmdbd && sudo systemctl status slurmdbd**

● slurmdbd.service - Slurm DBD accounting daemon
     Loaded: loaded (/usr/lib/systemd/system/slurmdbd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-03-09 17:15:43 CET; 10ms ago
       Docs: man:slurmdbd(8)
   Main PID: 2597522 (slurmdbd)
      Tasks: 1
     Memory: 1.6M (peak: 1.8M)
        CPU: 5ms
     CGroup: /system.slice/slurmdbd.service
             └─2597522 /usr/sbin/slurmdbd -D -s

Mar 09 17:15:43 NeoPC-mat systemd: Started slurmdbd.service - Slurm DBD accounting daemon.
Mar 09 17:15:43 NeoPC-mat (slurmdbd): slurmdbd.service: Referenced but unset environment variable evaluates to an empty string: SLURMDBD_OPTIONS
Mar 09 17:15:43 NeoPC-mat slurmdbd: slurmdbd: Not running as root. Can't drop supplementary groups
Mar 09 17:15:43 NeoPC-mat slurmdbd: slurmdbd: accounting_storage/as_mysql: _check_mysql_concat_is_sane: MySQL server version is: 5.5.5-10.11.8-MariaDB-0ubuntu0.24.04.1

**sudo systemctl restart slurmctld && sudo systemctl status slurmctld**

● slurmctld.service - Slurm controller daemon
     Loaded: loaded (/usr/lib/systemd/system/slurmctld.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-03-09 17:15:52 CET; 11ms ago
       Docs: man:slurmctld(8)
   Main PID: 2597573 (slurmctld)
      Tasks: 7
     Memory: 1.8M (peak: 2.8M)
        CPU: 4ms
     CGroup: /system.slice/slurmctld.service
             ├─2597573 /usr/sbin/slurmctld --systemd
             └─2597574 "slurmctld: slurmscriptd"

Mar 09 17:15:52 NeoPC-mat systemd: Starting slurmctld.service - Slurm controller daemon...
Mar 09 17:15:52 NeoPC-mat (lurmctld): slurmctld.service: Referenced but unset environment variable evaluates to an empty string: SLURMCTLD_OPTIONS
Mar 09 17:15:52 NeoPC-mat slurmctld: slurmctld: slurmctld version 23.11.4 started on cluster mat_workstation
Mar 09 17:15:52 NeoPC-mat systemd: Started slurmctld.service - Slurm controller daemon.
Mar 09 17:15:52 NeoPC-mat slurmctld: slurmctld: accounting_storage/slurmdbd: clusteracct_storage_p_register_ctld: Registering slurmctld at port 6817 with slurmdbd

**sudo systemctl restart slurmd && sudo systemctl status**

● slurmd.service - Slurm node daemon
     Loaded: loaded (/usr/lib/systemd/system/slurmd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-03-09 17:16:02 CET; 9ms ago
       Docs: man:slurmd(8)
   Main PID: 2597629 (slurmd)
      Tasks: 1
     Memory: 1.5M (peak: 1.9M)
        CPU: 13ms
     CGroup: /system.slice/slurmd.service
             └─2597629 /usr/sbin/slurmd --systemd

Mar 09 17:16:02 NeoPC-mat systemd: Starting slurmd.service - Slurm node daemon...
Mar 09 17:16:02 NeoPC-mat (slurmd): slurmd.service: Referenced but unset environment variable evaluates to an empty string: SLURMD_OPTIONS
Mar 09 17:16:02 NeoPC-mat slurmd: slurmd: slurmd version 23.11.4 started
Mar 09 17:16:02 NeoPC-mat slurmd: slurmd: slurmd started on Sun, 09 Mar 2025 17:16:02 +0100
Mar 09 17:16:02 NeoPC-mat slurmd: slurmd: CPUs=16 Boards=1 Sockets=1 Cores=8 Threads=2 Memory=128445 TmpDisk=575645 Uptime=2069190 CPUSpecList=(null) FeaturesAvail=(null) FeaturesActive=(null)
Mar 09 17:16:02 NeoPC-mat systemd: Started slurmd.service - Slurm node daemon.

If needed, I can attach the results for the corresponding journalctl, but no error is shown other than these two messages slurmd.service: Referenced but unset environment variable evaluates to an empty string: SLURMD_OPTIONS and slurmdbd: Not running as root. Can't drop supplementary groups in the journalctl -fu slurmd and in the journalctl -fu slurmdbd, respectively. For some reason, however, I'm unable to run sinfo in a new tab even after setting the link the *slurm.conf* in my *.bashrc*... this is what I'm prompted with > sinfo: error: Couldn't find the specified plugin name for auth/munge > looking at all files sinfo: error: cannot find auth plugin for > auth/munge sinfo: error: cannot create auth context for auth/munge > sinfo: fatal: failed to initialize auth plugin which seems to depend on munge but I'm cannot really understand to what specifically — it is my first time installing Slurm. Any help is much appreciated, thanks in advance!

If I try to login this way, it works. $ mariadb --user blogbot -p"password" If I try to login this way, it doesn't work. $ mariadb --user blogbot -p Enter password: ERROR 1045 (28000): Access denied for user 'blogbot'@'localhost' (using password: YES) I tried many times both typing and pasting the password, and it seems clear to me that the problem is with the method. --- What do you think this might be due to? I just noticed the password includes a ', is this prohibited in a password?

I have Persian character in my MariaDB database, when I select data from tables and show in terminal, Persian is not supported and bad are displayed.

We are experiencing a swap consumption problem when backing up our database. Every evening at 01am we run the mariabackup command and during the process swap usage rises sharply until it reaches 100% and only drops back to normal usage around 10am at best. The VM has an Alamalinux 8.4 OS, around 60GB RAM and a 4GB SWAP partition. Normal” resource utilization (excluding backup) is around 70-80% of RAM and 70-80% of SWAP. The vm.swapiness value has been set to 0, but this does not change the SWAP consumption. RAM usage remains fairly stable outside or during evening backups. Do you have any idea why SWAP is used so much during backups? Is this normal? Do you have any recommendations? --- after checking, it seems that the swap overconsumption is caused by the tar command issued after the mariabackup to archive the command result. Is there any way of obtaining a tar file directly from the mariabackup command? For your information: - the mariabackup command takes about 5 min, while the tar command takes about 1 hour. - the possibility of increasing the swap to 8GB should be tested. - in our context, deleting the swap partition is not possible for administrative reasons.

This script bash makes the data extraction to Oracle DB (another server), processing it and insert into MariaDB (my server), but the insertion it's misaligned and let it some columns in blank. * This is the code:

-bash
    #!/bin/bash
    
    ORACLE_USER="user"
    ORACLE_PASSWORD="password"
    ORACLE_DB="IP/SID"
    
    MYSQL_USER="user"
    MYSQL_PASSWORD="password"
    MYSQL_DB="DB"
    
    echo "Fetching data from Oracle..."
    ORACLE_DATA=$(sqlplus -s "$ORACLE_USER/$ORACLE_PASSWORD@$ORACLE_DB" > SALIDA.TXT
    
    echo "Data insertion completed."

* And the results are like this:

Region:
    
    Central:
    
    Nombre_Banco:
    
    Modelo:
    
    Bateria:
    
    Tecnologia:
    
    Amperaje_CA:
    
    Medido:
    
    Porcentaje:
    
    Voltaje:
    
    Voltaje_AC:
    
    Creado:
    
    Region: REGION 7
    
    Central: LERFIC
    
    Nombre_Banco: 7LERFICCT1B6
    
    Modelo: BATERIA GNB ABSOLYTE, 100A-19 896AH
    
    Bateria:
    
    Tecnologia:
    
    Amperaje_CA:
    
    Medido:
    
    Porcentaje:
    
    Voltaje:
    
    Voltaje_AC:
    
    Creado:
    
    Region: J10B                                                                                                                        
    
    Central: TYPHOON(TY1)
    
    Nombre_Banco: 0
    
    Modelo: 2016-12-30
    
    Bateria: 54.45
    
    Tecnologia: 2.25
    
    Amperaje_CA: 0
    
    Medido: 2017-01-10
    
    Porcentaje:
    
    Voltaje:
    
    Voltaje_AC:
    
    Creado:

Can ClamAV help detect malicious files (ie malware, rootkits, etc) for a MySQL/MariaDB server, specifically the /var/lib/mysql data folder? The database server is a single role and locked down both by firewall and MariaDB user host restriction.

I have a brand new AlmaLinux 9.4 installation with my hosting company and it appears to have been pre-installed with a LAMP stack. The MariaDB server version currently running is MariaDB 10.5.22 but I notice the release notes for AlmaLinux 9.4 mention an updated module stream to MariaDB 10.11 I am wondering how I can upgrade MariaDB. Doing dnf update and dnf upgrade tells me there is nothing to do. Doing dnf search mariadb lists a bunch of MariaDB stuff, but doesn't actually say the version. Obviously doing dnf install mariadb tells me Package mariadb-3:10.5.22-1.el9_2.alma.1.x86_64 is already installed So how would I upgrade MariaDB to the later version of MariaDB 10.11, **but still stick with a package officially supported and maintained by AlmaLinux**?

I'm using mariadb with nodejs on centos 8. Whenever I add process.env variables to my mysql.createConnection function I get error Access denied for user \'root\'@\'localhost\' (using password: NO) but it worked before I replaced code like host: localhost with host: process.env.DATABASE_HOST. ---------- Code that worked before using .env varaibles : const express = require('express'); const mysql = require("mysql"); const dotenv = require('dotenv'); dotenv.config({ path: './.env'}); const app = express(); const db = mysql.createConnection({ host: 'localhost', user: 'root', password: 'DBPASSWORD', database: 'nodejs-login' }); db.connect( (error) => { if(error) { console.log(error) } else { console.log("MySQL Connected...") } }) app.get("/", (req, res) => { res.send("

Home page

") }); app.listen(3000, () => { console.log("server started on Port 3000"); }) Terminal: server started on Port 3000 MySQL Connected... ---------- After adding .env variables: const express = require('express'); const mysql = require("mysql"); const dotenv = require('dotenv'); dotenv.config({ path: './.env'}); const app = express(); const db = mysql.createConnection({ host: process.env.DATABASE_HOST, user: process.env.DATABASE_USER, password: process.env.DATABASE_PASSWORD, database: process.env.DATABASE }); db.connect( (error) => { if(error) { console.log(error) } else { console.log("MySQL Connected...") } }) app.get("/", (req, res) => { res.send("

Home page

") }); app.listen(3000, () => { console.log("server started on Port 3000"); }) Project location on my system and project files: $ pwd /var/www/node $ ls -a . .. app.js .env node_modules package.json package-lock.json .env file content: DATABASE = nodejs-login DATABASE_HOST = localhost DATABASE_USER = root DATABASE_PASSSWORD = "DBPASSWORD" Terminal: server started on Port 3000 { Error: ER_ACCESS_DENIED_ERROR: Access denied for user 'root'@'localhost' (using password: NO) at Handshake.Sequence._packetToError (/var/www/node/node_modules/mysql/lib/protocol/sequences/Sequence.js:47:14) at Handshake.ErrorPacket (/var/www/node/node_modules/mysql/lib/protocol/sequences/Handshake.js:123:18) at Protocol._parsePacket (/var/www/node/node_modules/mysql/lib/protocol/Protocol.js:291:23) at Parser._parsePacket (/var/www/node/node_modules/mysql/lib/protocol/Parser.js:433:10) at Parser.write (/var/www/node/node_modules/mysql/lib/protocol/Parser.js:43:10) at Protocol.write (/var/www/node/node_modules/mysql/lib/protocol/Protocol.js:38:16) at Socket. (/var/www/node/node_modules/mysql/lib/Connection.js:88:28) at Socket. (/var/www/node/node_modules/mysql/lib/Connection.js:526:10) at Socket.emit (events.js:198:13) at addChunk (_stream_readable.js:288:12) -------------------- at Protocol._enqueue (/var/www/node/node_modules/mysql/lib/protocol/Protocol.js:144:48) at Protocol.handshake (/var/www/node/node_modules/mysql/lib/protocol/Protocol.js:51:23) at Connection.connect (/var/www/node/node_modules/mysql/lib/Connection.js:116:18) at Object. (/var/www/node/app.js:16:4) at Module._compile (internal/modules/cjs/loader.js:778:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12) at Function.Module._load (internal/modules/cjs/loader.js:585:3) at Function.Module.runMain (internal/modules/cjs/loader.js:831:12) code: 'ER_ACCESS_DENIED_ERROR', errno: 1045, sqlMessage: 'Access denied for user \'root\'@\'localhost\' (using password: NO)', sqlState: '28000', fatal: true }