[rt-users] Testing 4.0.0rc5 - experiences upgrading from 3.6.4 on RHEL6

[Chia-liang Kao]

Darren,
>
> On Feb 24, 2011, at 7:04 PM, Darren Nickerson wrote:
>>
>> That FD is a network connection to our database server:
>>
>> [root at rt4 Plack-0.9970]# ls -l /proc/30310/fd/1
>> lrwx------. 1 root root 64 Feb 24 17:44 /proc/30310/fd/1 -> socket: 
>> [281592]
>> [root at rt4 Plack-0.9970]# netstat -antep | grep 281592
>> tcp        0      5 10.0.12.149:49410            
>> 10.0.11.100:3306            ESTABLISHED 48         281592     30310/ 
>> httpd
>>
>> The database server has no record of that tcp connection any  
>> longer, and mysqladmin processlist shows all threads sleeping.
>
> *bump* any thoughts on this?
>
> Should I be looking outiside of RT for a fix for this? Is this more  
> likely to be a kernel/networking problem in RHEL6 or with mod_perl  
> or the MySQL DBD/DBI stuff? Looks like RT is using persistent  
> database connections, but that when the lockup occurs it's usually  
> because apache is waiting to get data back from a MySQL socket that  
> no longer exists on the database server ...

It seems the issue is with apache2 and plack.  i can reproduce the  
stalled connection (however not always) with the
plack-req.psgi example from the plack dist, with apache 2.2.16 on  
ubuntu maverick.  however it's a bit different from yours.

strace says:

close(0)                                = 0
read(5, 0x7fffff1f67af, 1)              = -1 EAGAIN (Resource  
temporarily unavailable)
accept(4, {sa_family=AF_INET, sin_port=htons(64924),  
sin_addr=inet_addr("114.44.215.78")}, [16]) = 0
fcntl(0, F_GETFD)                       = 0
fcntl(0, F_SETFD, FD_CLOEXEC)           = 0
getsockname(0, {sa_family=AF_INET, sin_port=htons(6254),  
sin_addr=inet_addr("10.130.158.43")}, [16]) = 0
fcntl(0, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(0, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
read(0, 0x7f8e98b0bf58, 8000)           = -1 EAGAIN (Resource  
temporarily unavailable)
poll([{fd=0, events=POLLIN}], 1, 300000


Cheers,
CLK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110302/a9ef63d5/attachment.htm>