On Fri, Jul 07, 2006 at 03:39:44PM +0200, Xavier Montagutelli wrote:
> Hello list,
>
> We are using the Zend php distribution, with Oracle support
> (ZendCoreForOracle-v1.3.1), inside a vserver. The Oracle server is on
> another machine.
>
> The vserver works fine, we can connect to Oracle. But after some time,
> we are unable to make new connections. I can't reproduce the bug on
> demand, but we are facing it from time to time (once every 1 to 3
> weeks, http server with a light load).
>
> A vserver restart is not sufficient : we have to reboot the *host*
> to make it works again. I suspect that even a bug in php or oracle
> shouldn't get us to this situation. Or am I wrong ? Do you have any
> experience of this ? Can it be a bug in the vserver patch or in the
> kernel ?
sounds like a timeout issue .. note that network sockets
(especially TCP) have unusually long default timeouts
(some of them are in the range of several days) so it
might as well be that there are sockets remaining, waiting
for a connection close (which will never happen, because
the php script reached a timeout and was killed) so you
might want to analyse the situation ...
> Linux 2.6.16.16
> VServer vs2.0.2-rc20
>
> Doing "strace /usr/local/Zend/Core/bin/php connect.php" (a simple test
> script) :
>
> [...]
> lstat64("/root/connect.php", {st_mode=S_IFREG|0644, st_size=428, ...}) = 0
> setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
> rt_sigaction(SIGPROF, {0x815a660, [PROF], SA_RESTART}, {0x815a660, [PROF],
> SA_RESTART}, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
> _llseek(4, 0, [0], SEEK_SET) = 0
> read(4, "<?php\n\n#CONNECT web/[EMAIL PROTECTED]"..., 4096) = 428
> _llseek(4, 428, [428], SEEK_SET) = 0
> ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf975a78) = -1 ENOTTY
> (Inappropriate
> ioctl for device)
> read(4, "", 4096) = 0
> read(4, "", 8192) = 0
> close(4) = 0
> munmap(0xb7f64000, 4096) = 0
> mmap2(NULL, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xb6405000
> open("/usr/local/Zend/Core/lib/libociei.so", O_RDONLY) = 4
> read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P&\0\000"..., 512) =
> 512
> fstat64(4, {st_mode=S_IFREG|0777, st_size=70637812, ...}) = 0
> old_mmap(NULL, 70638612, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
> 0)
> = 0xb20a7000
> old_mmap(0xb6403000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
> MAP_DENYWRITE, 4, 0x435b000) = 0xb6403000
> close(4) = 0
> mprotect(0xb20a7000, 70631424, PROT_READ|PROT_WRITE) = 0
> mprotect(0xb20a7000, 70631424, PROT_READ|PROT_EXEC) = 0
> time(NULL) = 1152259134
> gettimeofday({1152259134, 27036}, NULL) = 0
> times(NULL) = -2123886524
> times(NULL) = -2123886524
> times(NULL) = -2123886524
> times(NULL) = -2123886524
>
> ant it goes on like this.
would be interesting to know if this problem happens
on the host too, which would point to a mainline
issue (feature) :)
> *Any* help would be very appreciated :-)
>
> I will try to update Zend + Linux + vserver next week, but the bug also
> occured with 2.6.16 + vs2.1.1rc14
HTH,
Herbert
> --
> Xavier Montagutelli Tel : +33 (0)5 55 45 77 20
> Service Commun Informatique Fax : +33 (0)5 55 45 75 95
> Universite de Limoges
> 123, avenue Albert Thomas
> 87060 Limoges cedex
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
