Spurious - "Access denied for user 'root'@'localhost' (using password: NO)" in the /var/log/mysql/error.log.1 file

I'm NOT having a login problem. Apparently, there are periodic automated login attempts, which fail and result in the warning "Access denied for user 'root'@'localhost' (using password: NO)" being recorded in the /var/log/mysql/error.log.1 file. I have no problems manually logging into MariaDB as root or manually logging into PHPMyAdmin as root. (Using Mint 20.2)

Have been wondering what could be causing this problem and how it could be resolved? ------------------------------------------------------------------------------------------------------------------------------------------------------------------ 2021-07-17 11:27:53 0 [Note] InnoDB: Using Linux native AIO 2021-07-17 11:27:53 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-07-17 11:27:53 0 [Note] InnoDB: Uses event mutexes 2021-07-17 11:27:53 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-07-17 11:27:53 0 [Note] InnoDB: Number of pools: 1 2021-07-17 11:27:53 0 [Note] InnoDB: Using SSE2 crc32 instructions 2021-07-17 11:27:53 0 [Note] InnoDB: Initializing buffer pool, total size = 2G, instances = 8, chunk size = 128M 2021-07-17 11:27:53 0 [Note] InnoDB: Completed initialization of buffer pool 2021-07-17 11:27:53 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2021-07-17 11:27:53 0 [Note] InnoDB: 128 out of 128 rollback segments are active. 2021-07-17 11:27:53 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2021-07-17 11:27:53 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2021-07-17 11:27:53 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2021-07-17 11:27:53 0 [Note] InnoDB: Waiting for purge to start 2021-07-17 11:27:54 0 [Note] InnoDB: 10.3.29 started; log sequence number 385349830; transaction id 32047 2021-07-17 11:27:54 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2021-07-17 11:27:54 0 [Note] Plugin 'FEEDBACK' is disabled. 2021-07-17 11:27:54 0 [Note] InnoDB: Buffer pool(s) load completed at 210717 11:27:54 2021-07-17 11:27:54 0 [Note] Server socket created on IP: '0.0.0.0'. 2021-07-17 11:27:54 0 [Note] Reading of all Master_info entries succeeded 2021-07-17 11:27:54 0 [Note] Added new Master_info '' to hash table 2021-07-17 11:27:54 0 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.3.29-MariaDB-0ubuntu0.20.04.1-log' socket: '/run/mysqld/mysqld.sock' port: 3306 Ubuntu 20.04 2021-07-17 11:27:54 8 [Warning] Access denied for user 'root'@'localhost' (using password: NO) 2021-07-17 11:27:54 9 [Warning] Access denied for user 'root'@'localhost' (using password: NO) 2021-07-17 11:27:54 10 [Warning] Access denied for user 'root'@'localhost' (using password: NO)

Answer Answered by Daniel Black in this comment.

Because this is so soon after startup, I'm assuming the Mint service file has a trigger that attempts to run `mysql_upgrade` or something similar automaticly. It also could be a check that the mariadb service is running.

If there are entries at a periodic interval that would probably be a logrotate script attempting to integrate with the server to rotate log files.

Regular intervals could also be some monitoring program

Solutions include:

  • ignoring it
  • changing the root user to use unix_socket authentication only (as these scripts run as root) and this keeps it secure without a password. In 10.4 onwards unix_socket auth and passwords are supported at the same time.
  • find the two or more instances and edit their interaction with the server
  • remove the need, edit the service file to not attempt mysql_upgrade, and change the error-log to default blank (stdout) and let journalctl manage all the things done by logrotate (and disable the log-rotate).

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.