When you say you "installed php 5.3.x and then reverted to 5.2", did you
reinstall/upgrade OS and/or kernel too?
b.
On 28 March 2011 23:40, Bostjan Skufca <bostjan@xxxxxx> wrote:
> Great, please report back if/when you discover the cause.
>
> Meanwhile doing "man 2 flock" yields info about ENOLCK: "The kernel ran out
> of memory for allocating lock records." This concerns your new server. The
> old one does not support locking, or so it seems (EOPNOTSUPP).
>
> b.
>
>
>
> On 28 March 2011 23:15, Rob Adams <radams@xxxxxxxxxxxxx> wrote:
>
>> Bostjan,
>>
>> Thanks again for the tip. At this point, it looks like there is an issue
>> with my main file server. It's weird that the older servers were working
>> with it fine though (by instantly failing on lock), so I originally thought
>> it might be a php issue. I think I'm making progress on it now though.
>>
>> -- Rob
>>
>>
>>
>> On 3/28/2011 12:08 PM, Rob Adams wrote:
>>
>>> On 3/26/2011 11:07 AM, Bostjan Skufca wrote:
>>>
>>>> Can you strace it's execution and see where your delay is comming
>>>> from? If
>>>> you are using apache, make it create just one child and strace that
>>>> one when
>>>> you generate a request.
>>>>
>>>
>>> Thanks for the advice. I installed strace on the new server, and it has
>>> a thirty second delay on the flock call (opening the session file):
>>>
>>> open("/path/to/session/sess_SESSIONID", O_RDWR|O_CREAT, 0600) = 20
>>> flock(20, LOCK_EX) = -1 ENOLCK (No locks available)
>>> fcntl64(20, F_SETFD, FD_CLOEXEC) = 0
>>> fstat64(20, {st_mode=S_IFREG|0644, st_size=13, ...}) = 0
>>> pread64(20, "cpixUser|b:1;", 13, 0) = 13
>>> gettimeofday({1301331125, 622954}, NULL) = 0
>>> gettimeofday({1301331125, 623046}, NULL) = 0
>>> brk(0x989d000) = 0x989d000
>>> gettimeofday({1301331125, 623301}, NULL) = 0
>>> pwrite64(20, "cpixUser|b:1;", 13, 0) = 13
>>> close(20) = 0
>>>
>>> This has the correct session file name (ie
>>> "/path/to/session/sess_SESSIONID").
>>>
>>> So then I installed strace on one of the older servers, to see what it
>>> was doing, and this is what I see where it is opening the session file:
>>>
>>> open("\"M\235\240GU\21", O_RDWR|O_CREAT, 0600) = 9
>>> flock(9, LOCK_EX) = -1 EOPNOTSUPP (Operation not supported)
>>> fcntl(9, F_SETFD, FD_CLOEXEC) = 0
>>> fstat(9, {st_mode=S_IFCHR|040, st_rdev=makedev(113, 1114152), ...}) = 0
>>> lseek(9, 0, SEEK_SET) = 0
>>> read(9, "cpixUser|b:1;"..., 13) = 13
>>> gettimeofday({540876916, 1078020164}, {3221773391, 671636288}) = 0
>>> sigprocmask(SIG_BLOCK, NULL, []) = 0
>>> lseek(9, 0, SEEK_SET) = 0
>>> write(9, "cpixUser|b:1;"..., 13) = 13
>>> close(9) = 0
>>>
>>> I don't know why it has the session file as this: "\"M\235\240GU\21".
>>>
>>> So it looks like the flock(?) is taking 30 seconds to timeout on the new
>>> server, and failing instantly on the old ones. On the new server, I have
>>> a message in /var/log/messages that reads:
>>>
>>> Mar 28 10:38:34 webServer kernel: lockd: server mainFileServer not
>>> responding, timed out
>>>
>>> I get this message evertime I call session_start(). I have tried
>>> reloading the new server from scratch (CentOS 5.5, php 5.2.17, apache
>>> 2.2) and it is still doing the same thing.
>>>
>>>
>>>
>>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
