MySQL Bugs: #43821: Agent Fails On 32 bit Systems

Bug #43821	Agent Fails On 32 bit Systems
Submitted:	24 Mar 2009 7:08	Modified:	21 Jul 2009 9:57
Reporter:	Mikiya Okuno	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Agent	Severity:	S3 (Non-critical)
Version:	2.0.5.7153	OS:	Linux (RHEL/CentOS 32-bit)
Assigned to:	MC Brown	CPU Architecture:	Any

Description:
Monitor Agent doesn't work due to the error like follwoing:

2009-03-24 16:01:09: (debug) chassis.c:1091: current RLIMIT_NOFILE = 4398046512128 (hard: 577792033385921489)
2009-03-24 16:01:09: (debug) chassis.c:1095: trying to set new RLIMIT_NOFILE = 4398046519296 (hard: 577792033385921489)
2009-03-24 16:01:09: (critical) chassis.c:1097: could not raise RLIMIT_NOFILE to 8192, Invalid argument (22). Current limit still 13811918798715880448.
2009-03-24 16:01:09: (message) MySQL Monitor Agent 2.0.5.7153 started.

This happens on the following environment as well as CentOS 5.2 32-bit:

$ ./mysql-monitor-agent -V
 mysql-proxy 0.7.0
 glib2: 2.16.3
 libevent: 1.4.6-stable
 proxy: 0.7.0
 monitor: 0.7.0
 MySQL Monitor Agent(agent): 2.0.5.7153
 admin: 0.7.0

$ cat /etc/redhat-release
 Red Hat Enterprise Linux ES release 3 (Taroon Update 5)

$ uname -a
 Linux xxxx 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 i686 i386 GNU/Linux

It appears that the agent attempts to set larger values than 2^32 for struct rlimit.rlim_cur or rlim_max. This might be caused by type some type mismatch in chassis.c.

How to repeat:
Install MEM agent on x86 Linux platform, and start it.

Suggested fix:
nada

The agent does not fail, it will continue to function.
It merely warns that it cannot the maximum number of open files.

The type mismatch in the log message is a bug, however.

Does the agent crash or shutdown for you?

Hi,

I confirmed that the agent was not functioning due to other reason. After fixing it, the agent is running finely except for the setrlimit() error.

While it doesn't prevent the agent from functioning, the type-mismatch itself is a bug however. So please fix it ;)

BR,
Mikiya

The problem has happened on the following 64-bit machine as well. It appears that the problem is not 32-bit specific. The type must be badly defined.

Linux xxxx.xxxxx 2.6.18-92.1.17.el5xen #1 SMP Wed Oct 22 04:35:07 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

Found this problem today too.

For me it is questionable at all, why an agent has to raise the RLIMIT_NOFILE to 8192 at all...? 1024 file handles should be more than enough. Is it not?

Setting to P2 per Mark Leith because of high confusion level (i.e. it's not a serious problem, it's just confusing a lot of people) -- need better error message.

Patch installed in versions => 2.1.0.1056.

Verified fixed on 2.1.0.1056

On cases where the agent cannot increase the open files limit,
you get a message like this

(message) chassis.c:1106: could not raise RLIMIT_NOFILE to 8192, Invalid argument (22). Current limit still 100.

Instead of the critical message you used to get.

An entry was added to the 2.1.0 changelog:

The Agent failed on Linux 32-bit systems with the following error:

2009-03-24 16:01:09: (debug) chassis.c:1091: current RLIMIT_NOFILE = 4398046512128 (hard:
577792033385921489)
2009-03-24 16:01:09: (debug) chassis.c:1095: trying to set new RLIMIT_NOFILE =
4398046519296 (hard: 577792033385921489)
2009-03-24 16:01:09: (critical) chassis.c:1097: could not raise RLIMIT_NOFILE to 8192,
Invalid argument (22). Current limit still 13811918798715880448.
2009-03-24 16:01:09: (message) MySQL Monitor Agent 2.0.5.7153 started.

This happened with the following environment:

$ ./mysql-monitor-agent -V
 mysql-proxy 0.7.0
 glib2: 2.16.3
 libevent: 1.4.6-stable
 proxy: 0.7.0
 monitor: 0.7.0
 MySQL Monitor Agent(agent): 2.0.5.7153
 admin: 0.7.0

$ cat /etc/redhat-release
 Red Hat Enterprise Linux ES release 3 (Taroon Update 5)

$ uname -a
 Linux xxxx 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 i686 i386
GNU/Linux

The same error also occurred on CentOS 5.2 32-bit systems.