On Feb 21, 2009, at 9:28 AM, Joshua Zhu wrote:

> Sorry, maybe I should not believe the POSIX specification, which  
> cheated me :(
> (
> http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/resource.h.html
> rlim_t
>    Unsigned integer type used for limit values.
> )

well, it _is_ an integer type, just not int, so the implementations  
seem to be in accordance with the spec. :)

>> ...
>> On Linux it seems to be a signed int64...
>
> Not exactly, I'm afraid. It's an _unsigned long int_ on Linux. And  
> all my Linux systems on hand proved this.

'k, i scraped header files from the net and saw a signed long int.  
maybe that used to be a bug (many UNIXes in fact only use 63 bits of  
rlim_t because of old buggy implementations that used signed longs for  
this purpose).

> Sadly, I have no other unix systems available. But I think treating  
> rlim_t as unsigned long on other platforms should be fine as well  
> (e.g. unsigned long is still 64 bits long on your Mac).
> This is a trivial problem though (just debug message).

i'll be working to on an automatic build process over the weekend.  
that will give us results on all platforms MySQL itself is compiled  
on, including some really arcane systems. then we should know more.

>> Now, you could argue that setting rlim_max = max_open_files will  
>> work, because either
>>  a) max_open_files is lower then rlim_max and if it's lower then we  
>> are fine or
>>  b) max_open_files is larger then rlim_max (and transitively is  
>> larger than rlim_cur) thus we will fail anyway.
>> My only objection is that there's no real value in modifying the  
>> hard limit, because it would not make a difference.
>> I doubt that we would get a signal for exceeding the soft limit of  
>> NOFILES, but I might be wrong. If we do, we could try to further  
>> increase the soft limit, but if we lowered the hard limit that  
>> would not be an option any more. Of course, none of that code has  
>> been written yet.
>
> Imagine I'm the root user and rlim_max now is 1024 (actually default  
> value on most systems). When I raise the max_open_files to any  
> number greater than 1024, say 8192, it won't work at all. Is it too  
> confusing, since I'm already root??
> By the way, IMHO, setting both the values of rlim_cur and rlim_max  
> is a conventional way in many server programs.
> So, how about this?

this looks like the right thing to do, thank you!
i'll take another look at the format string to use on the different  
platforms. we should be able to hinge that on sizeof(rlim_t) and use a  
simple macro if necessary.

> === modified file 'src/chassis.c'
> --- src/chassis.c	2009-01-15 17:45:43 +0000
> +++ src/chassis.c	2009-02-21 07:47:52 +0000
> @@ -980,19 +980,20 @@
> 				  G_STRLOC, g_strerror(errno), errno);
> 	} else {
> 		rlim_t soft_limit = max_files_rlimit.rlim_cur;
> -		g_debug("%s: current RLIMIT_NOFILE = %llu (hard: %llu)",  
> G_STRLOC, max_files_rlimit.rlim_cur, max_files_rlimit.rlim_max);
> +		g_debug("%s: current RLIMIT_NOFILE = %lu (hard: %lu)", G_STRLOC,  
> max_files_rlimit.rlim_cur, max_files_rlimit.rlim_max);
>
> 		max_files_rlimit.rlim_cur = max_files_number;
> +		max_files_rlimit.rlim_max = MAX(max_files_number,  
> max_files_rlimit.rlim_max);
>
> -		g_debug("%s: trying to set new RLIMIT_NOFILE = %llu (hard:  
> %llu)", G_STRLOC, max_files_rlimit.rlim_cur,  
> max_files_rlimit.rlim_max);
> +		g_debug("%s: trying to set new RLIMIT_NOFILE = %lu (hard: %lu)",  
> G_STRLOC, max_files_rlimit.rlim_cur, max_files_rlimit.rlim_max);
> 		if (-1 == setrlimit(RLIMIT_NOFILE, &max_files_rlimit)) {
> -			g_critical("%s: could not raise RLIMIT_NOFILE to %u, %s (%d).  
> Current limit still %llu.", G_STRLOC, max_files_number,  
> g_strerror(errno), errno, soft_limit);
> +			g_critical("%s: could not raise RLIMIT_NOFILE to %u, %s (%d).  
> Current limit still %lu.", G_STRLOC, max_files_number,  
> g_strerror(errno), errno, soft_limit);
> 		} else {
> 			if (-1 == getrlimit(RLIMIT_NOFILE, &max_files_rlimit)) {
> 				g_warning("%s: cannot get limit of open files for this process.  
> %s (%d)",
> 						  G_STRLOC, g_strerror(errno), errno);
> 			} else {
> -				g_debug("%s: set new RLIMIT_NOFILE = %llu (hard: %llu)",  
> G_STRLOC, max_files_rlimit.rlim_cur, max_files_rlimit.rlim_max);
> +				g_debug("%s: set new RLIMIT_NOFILE = %lu (hard: %lu)",  
> G_STRLOC, max_files_rlimit.rlim_cur, max_files_rlimit.rlim_max);
> 			}
> 		}
> 	}

+1

> In the end, I think it doesn't matter if this revised patch is  
> objected again. Maybe we just have different angles of view. And I'm  
> glad to discuss these issues with you :D (Otherwise, I'll create  
> another branch to propose the new patch, happily.)

just trying to do the right thing here :) at times it seems like  
nitpicking, but in the end it saves us from revisiting it again and  
again...

> Anyway, thank you very much :)

thank you for the persistence!

cheers,
-k
-- 
Kay Roepke
Software Engineer, MySQL Enterprise Tools

Sun Microsystems GmbH    Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering                    HRB MUC 161028