Increase open-files-limit in MariaDB on CentOS 7 with systemd

Mattias Geniar, Wednesday, April 29, 2015 - last modified: Thursday, April 30, 2015

Gone are the days where simply changing /etc/my.cnf would be sufficient. Enter the new systemd world.

systemd itself has a limit that controls how many files a service can open, regardless if what you configure in /etc/my.cnf or /etc/security/limits.conf.

To increase the open files limit in MariaDB running on a RHEL or CentOS 7 with systemd, do the following.

First, create a new directory that will hold the MariaDB service changes in systemd. By making your changes here, you'll make sure that package upgrades that would/could overwrite the mariadb.service file don't remove your own changes.

$ mkdir -p /etc/systemd/system/mariadb.service.d/

Next, configure systemd so that the MariaDB service can open more files.

$ cat /etc/systemd/system/mariadb.service.d/limits.conf
[Service]
LimitNOFILE=10000

In order for systemd to be aware of those changes, you have to reload the systemd daemon. This only reloads the configs that systemd knows about, it does not restart any actual service.

$ systemctl daemon-reload

The above tells systemd that MariaDB can open 10000 files of it wants. Restart the MariaDB service now to make those changes stick.

$ systemctl restart mariadb

And you're done.
Increase the value in /etc/systemd/system/mariadb.service.d/limits.conf if needed.

These changes are also "documented" in the mariadb.service service file in systemd.

$ cat /usr/lib/systemd/system/mariadb.service
...
# 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 /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
# http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F

# For example, if you want to increase mariadb's open-files-limit to 10000,
# you need to increase systemd's LimitNOFILE setting, so create a file named
# "/etc/systemd/system/mariadb.service.d/limits.conf" containing:
#	[Service]
#	LimitNOFILE=10000

# Note: /usr/lib/... is recommended in the .include line though /lib/...
# still works.
# Don't forget to reload systemd daemon after you change unit configuration:
# root> systemctl --system daemon-reload

Just another thing to keep in mind.



Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

Philip Van Hoof Friday, May 1, 2015 at 14:17 (permalink)

I’m sorry, but the limit of open file descriptors is not a limit imposed on you by systemd. Systemd is just making it configurable for you uniformly. Before that you had to use for example ulimit to achieve a similar result. It’s not something evil Lennart did to you with his systemd thing. Because the beginning of your blog makes it sound a bit like that (gone are the days).

So instead, you could also have written something like: gone are the days that you had to use ulimit, check /proc/sys/fs/file-max launch weird commands like sysctl -w fs.file-max=100000 and/or tamper with /etc/sysctl.conf … and all this slightly different on each and every goddamned Linux based distribution; because today systemd makes it uniform how to configure the maximum amount of open file descriptors the underlying OS will allow for a given service.

That means that today MariaDB can put this in its packaging and its source code distribution in a uniform way, and every Linux based distribution that uses systemd will “just do the right thing” because of it. Without all the angry sysadmins having a say about it and/or thinking they know better how to do this. And if they do want to change it, they now have a uniform way to angrily change it. Without having to learn it for each and every goddamn Linux based distribution slightly differently.

But I’m sure that it’s not going to be good that you can’t choose anymore how to configure the maximum amount of open file descriptors. Because choice is so f. important (that it’s unbelievable). And that’s precisely why the old ways will still all keep on working just fine for the most angry and stubborn sysadmins among us.

The most angry and most stubborn sysadmins can even still configure MariaDB to be started by systemd using its old init.d bash-based shell scripts. Just like the good old days. And do all the ulimit stuff over there. If that makes them feel any better.

It would make me feel dirty and violently raped by an angry sysadmin, but that’s just me and my choices and feelings. Therefore I will prefer the systemd way from now on. Strongly.

Reply


    Mattias Geniar Friday, May 1, 2015 at 16:27 (permalink)

    I actually didn’t mean this in any negative way, sorry if it came across like that.

    Thanks for clarifying though, there’s a fellow systemd enthousiast here. ;-)

    Reply


      Philip Van Hoof Friday, May 1, 2015 at 16:37 (permalink)

      Yes, rereading and checking some of your other articles on system I realize you didn’t mean it like that.

      I guess it’s just that I’ve been keeping a distance with these systemd debates for so long now, and sometimes when I see something that is just technically incorrect .. I have this silly urge to want to correct people. And this time I couldn’t resist it. Because this blog item of yours was one of the nicer ones that I found worthy of commenting on.

      There will be harsh punishment for me in hell for that. Sorry world.

      Reply


        Mattias Geniar Sunday, May 3, 2015 at 23:27 (permalink)

        systemd is and will remain an item for debate. Everybody (in the Linux community) seems to have an opinion. And most of them seem to conflict.

        + only those with a very outspoken opinion, be it pro or con, seem to speak out. So we’ve got the heaviest supporters of both sides, verbally fighting with each other. It’s a recipe for disaster …

        Reply


    Chris Mair Monday, August 17, 2015 at 09:45 (permalink)

    I’m probably a stubborn sysadmin. To this day I don’t get why Red Hat had to completely break the old behaviour.
    Couldn’t there have been some sort of default systemd behaviour that honours /etc/security/limits.conf, potentially overridden by service-specific systemd settings? Or at the very least, more detailed hints in limits.conf ?
    I don’t hate systemd or anything, but the transition could have been smoother with a bit of common sense. My idea is that you systemd enthusiasts hate us casual sysadmin more than the other way round ;)

    — Chris

    Reply


      Philip Van Hoof Monday, August 17, 2015 at 11:53 (permalink)

      As far as I know will your Linux distribution still honour /etc/security/limits.conf just like before. The systemd only adds a early-boot possibility, that possibly happens even before anything reads the limits.conf file, that can per service started configure for that service the FD limits. And this in a uniform way.

      So basically the old behaviour is not broken. It’s not even deprecated. It’s just not necessarily something systemd will care about. It leaves it as is. I wouldn’t see the point in doing a synchronization of limits.conf to systemd because as far as I understood limits.conf is for per-user and per-group and not per-service. Whereas systemd is (focused on services).

      Reply


Kirby Thursday, September 3, 2015 at 15:20 (permalink)

Another systemd fanboy. And not a very nice one either.

Reply


    Kirby Thursday, September 3, 2015 at 15:25 (permalink)

    My previous comment was directed at Philip Van Hoof – not the author of said article.
    While I’m at it – I wonder how many systemd supported are actually sysadmins? Seems most of them say ‘but my computer boots up faster.’ Really? I usually can go a year without rebooting.

    Reply


JCC1 Thursday, February 18, 2016 at 20:03 (permalink)

This seems to be yet another case of Works-for-me-on-my-laptop without any design input from real-world admins not operating in the very specific operating space the “kabal” cares about (namely, containers).

limits.conf/.d is great. Starting services is great. There’s no reason for new limits to be added in *by default* at the service level unless you’re someone who’s never actually had to deal with that domain space and doesn’t have to think about the churn.

There are many ways of running systems out there, not just how the distro initially conceptualized it, and certainly not just how the systemd authors conceptualized it. (Think of installs with multiple parallel mysql/mariadb setups running on the same box.)

Taken in isolation, it’s just an annoyance. But there are a LOT of systemd annoyances like this. It might be a fine idea, but it’s not an idea that anyone in particular ASKED for, it’s just what the “kabal” decided to do.

As someone famous once said, “People don’t like to be meddled with.”

Reply


Jamie Saturday, October 29, 2016 at 06:14 (permalink)

FWIW I’m finding that the file has to be called /etc/systemd/system/mariadb.service.d/filelimit.conf

mariadb-server-5.5.44-2.el7.centos.x86_64

Reply


Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links