MySQL wont run on Ubuntu 20.04.3 LTS under WSL

jp flag

I've been going round and round trying to solve the below issue when trying to start MySQL:

2022-01-27T09:47:14.547946Z 0 [Warning] [MY-010139] [Server] Changed limits: max_open_files: 1024 (requested 8161)
2022-01-27T09:56:22.047681Z 0 [Warning] [MY-010142] [Server] Changed limits: table_open_cache: 431 (requested 4000) 
2022-01-27T09:56:22.265005Z 0 [Warning] [MY-010091] [Server] Can't create test file /var/lib/mysql/mysqld_tmp_file_case_insensitive_test.lower-test

I've tried upping my limits.conf file values, and in /etc/service however those values are all over 10000 (or in some cases 65535) however no matter what I change when I run:

ulimit -Sa | grep "open files"

The result is always:

open files (-n) 1024

Any help would be appreciated but I just can't see any other solutions?

I have no databases yet, I've not even managed to boot MySQL to log in once.

MySQL is Ver 8.0.27 Running on Ubuntu 20.04.3 LTS on WSL

in flag
Could you elaborate on what problem you're trying to solve? Do you have a database (or many databases) with thousands of tables? Are you running on a server with less than 1GB RAM? Which version of MySQL are you using? Does the DB use InnoDB or MyISAM? How is `mysql.cnf` configured? There's a lot that can cause the sort of problems expressed in your question ...
Aravona avatar
jp flag
I am literally trying to get a fresh install of MySQL server to run, I've no databases at all yet. I'm using WSL (as per my tag) - my mysql.cnf is out of the box, I've not changed it.
Liso avatar
sd flag
Have you try [this]( ?
Aravona avatar
jp flag
Yes, my LimitNOFILE is set to 10000 by default in that file. I've set it to 65535 in `etc\systemd\system\mysqld.service.d\limits.conf`
in flag
You wouldn’t happen to be running Node services in the same WSL container, would you?
Aravona avatar
jp flag
I have node installed yes (working to have a WP vhost set up with Sage 10 which uses npm)
in flag
Yeah, Node is really good at making simple things hard. Does `sudo sh -c "ulimit -n 65535 && exec su $LOGNAME"` give you a proper working environment? Alternatively, running this setup in a VirtualBox VM would be a good way to avoid the arbitrary limits imposed by WSL
NotTheDr01ds avatar
vn flag
@Aravona How are you starting mysql?
NotTheDr01ds avatar
vn flag
@Aravona Also, the more information you can give me on your current set-up the better. I'm happy to try to solve it. Right now, I know *why* `limits.conf` and other settings aren't working the way you'd expect (lack of PAM and Systemd support on WSL). I'm sure there's a workaround, but I need to be able to reproduce your problem before I can propose a solution, unfortunately.
mf flag

WSL does not have systemd. That is why your changes from /etc/systemd/system/mysqld.service.d/limits.conf are not applied. So ulimit -n returns 1024.

You can edit the /etc/security/limits.conf file in order to increase the limits for every user by appending the following lines:

* soft nofile 10000
* hard nofile 10000

By restarting mysql service, the above file is read an applied. In order to restart mysql service execute:

sudo service mysql restart

The limits will be changed for user mysql. To check this you can run the command:

ps -ef|grep -e ^mysql
mysql       90     1  0 18:28 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql      250    90  0 18:28 ?        00:00:01 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --log-error=/var/log/mysql/error.log

for pid in `ps -ef|grep -e ^mysql|awk '{print $2}'` ; do echo pid=$pid user=`ps -ef|awk '{if( $2 == '$pid' ) print $1}'`; sudo prlimit -p $pid --nofile ; done

pid=90 user=mysql
NOFILE   max number of open files 10000 10000 files
pid=250 user = mysql
NOFILE   max number of open files 10000 10000 files


It seems that for the normal user we have the same status (no change read for no file limit) because by default no login is executed. But if you run:

su <username>

then the limit files are read and ulimit -n will return 10000 also for the current user.


My answer was inspired by:


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.