MySQL Bugs: #62224: Setting open-files-limit above the hard limit won't be logged in errorlog

Bug #62224	Setting open-files-limit above the hard limit won't be logged in errorlog
Submitted:	22 Aug 2011 8:00	Modified:	23 Aug 2011 19:53
Reporter:	Daniël van Eeden	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S3 (Non-critical)
Version:	5.5.13, 5.6.3, 5.1.60	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	Contribution

Description:
According to the documentation mysqld tries to set the open files limit using setrlimit and will log a message to the error log if it fails.

- Default ----------------------------------
$ egrep '^(Limit|Max open files)' /proc/`pidof mysqld`/limits
Limit                     Soft Limit           Hard Limit           Units     
Max open files            1024                 4096                 files     

- Limit 4096 -------------------------------
$ egrep open.files.limit my.cnf 
open-files-limit		= 4096

$ egrep '^(Limit|Max open files)' /proc/`pidof mysqld`/limits
Limit                     Soft Limit           Hard Limit           Units     
Max open files            4096                 4096                 files 

From strace:
[pid  4402] setrlimit(RLIMIT_NOFILE, {rlim_cur=4*1024, rlim_max=4*1024}) = 0

- Limit 8192 -------------------------------
$ egrep open.files.limit my.cnf 
open-files-limit		= 8192

$ egrep '^(Limit|Max open files)' /proc/`pidof mysqld`/limits
Limit                     Soft Limit           Hard Limit           Units     
Max open files            1024                 4096                 files   

From strace:
[pid  3917] setrlimit(RLIMIT_NOFILE, {rlim_cur=8*1024, rlim_max=8*1024}) = -1 EPERM (Operation not permitted)

How to repeat:
- Set limit to 4096 (hard limit) and check the effective limit
 - The effective limit will be 4096

- Set limit above 4096 (hard limit) and check the effective limit
 - The effective will be 1024 instead of the configured limit
 - There should be a message in the error-log, but there isn't

http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_open-files-limit

Suggested fix:
Fix mysqld so that it will log failed setrlimit() statements.

mysqld uses this:
files= my_set_max_open_files(max_open_files);
wanted_files= 10+max_connections+table_cache_size*2;

which comes from mysys/my_file.c

The my_set_max_open_files only logs using DBUG_PRINT.

mysqld only logs if global_system_variables.log_warnings is set, but this seems only to happen if (files < wanted_files).

Patch for Bug #62224

Attachment: mysql_bug_62224.patch (text/x-patch), 592 bytes.

add Contribution tag

Example from the patch (open-files-limit=16000):
110822 10:45:38 [Warning] Could not increase number of max_open_files to more than 1024 (request: 16000)

Please note that 1024 is the soft limit, not the hard limit. That seems like a weird fallback. Using the hard limit would seem more logical

It seems to use rlim_cur instead of rlim_max fro getrlimits.
[pid 17103] getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=8*1024}) = 0
[pid 17103] setrlimit(RLIMIT_NOFILE, {rlim_cur=16000, rlim_max=16000}) = -1 EPERM (Operation not permitted)

Additional patch to set rlimit to the hard limit instead of the soft limit if it exceeds the hardlimit.

Attachment: mysql_bug_62224_2.patch (text/x-patch), 644 bytes.

After the second patch:
110822 11:08:31 [Warning] Could not increase number of max_open_files to more than 8192 (request: 16000)

Thank you for the report.

Verified as described.

Hi Daniël,

Thank you very much for the patch!

The problem that I see is this: you can specify the open-files-limit option in the [mysqld_safe] and/or the [mysqld] group in your configuration file.

mysqld_safe uses the ulimit -n call to set the limit, while mysqld uses the setrlimit call directly. mysqld mimics the behavior of the ulimit -n call:

[matt@mylab ~]$ ulimit -Sn 
1024
[matt@mylab ~]$ ulimit -Hn 
65536
[matt@mylab ~]$ ulimit -n 66000
-bash: ulimit: open files: cannot modify limit: Operation not permitted
[matt@mylab ~]$ ulimit -Sn 
1024

If you try to set the limit to anything beyond the hard limit, then it fails with an error and nothing is changed. 

So changing the behavior of mysqld--as done in the provided patch--would leave us with inconsistent behavior, and what could be considered unexpected behavior as well (if you're familiar with the standard UNIX behavior for ulimit).

What are your thoughts on this? If you have any additional or contradictory info, I'd be happy to look through it.

Thanks again!

Matt

I think it's good to keep the behaviour identical to the ulimit utility.

The real issue in this bug is that there is no error in the error log. But that seems to be fixed by the commit for Bug#16430532 in 5.6.12 by Marc Alff or by the commit for WL#6372 in 5.6.8 by Sergey Vojtovich. 

I've tested this with 5.6.16 and there the following error is logged:
2014-02-18 21:18:31 5792 [Warning] Buffered warning: Could not increase number of max_open_files to more than 4096 (request: 10000)

With 5.5.30 no error is logged.

So feel free to close this bug, I consider it fixed.

hello there,
i am having this issue with mysql version 5.6.25 comunity edition. 
i had changed the ulimits on the server but seems mysql doesnt take it. 
2015-07-29 12:41:46 24423 [Warning] Buffered warning: Could not increase number of max_open_files to more than 1024 (request: 20000)

2015-07-29 12:41:46 24423 [Warning] Buffered warning: Changed limits: table_open_cache: 431 (requested 2000)

@alexandra 

That is probably not this bug. 
Maybe post the output of this command on http://forums.mysql.com/
cat /proc/$(pidof mysqld)/limits