ID: 11058
Comment by: hachem at phptunisia dot com
Reported By: pat at mail dot rit dot edu
Status: Bogus
Bug Type: Network related
Operating System: OpenBSD 2.6
PHP Version: 4.0.6
New Comment:
restart the bind
Previous Comments:
------------------------------------------------------------------------
[2004-07-14 22:29:05] neil dot giarratana at lucidus dot net
Don't know if this helps at all but on RH9, if I do a "service network
restart", all is well again and I don't get that error anymore. Beats
the heck out of restarting the whole server
------------------------------------------------------------------------
[2004-06-30 18:17:09] webmaster at hg-carstyling dot de
i have that problem, too, on 4 machines running RH9, FC1 and FC2. I
spend some whole days to solve it, but cannot get the basic of this
problem.
On 1 machine i have serveral virt. domains, were i enter the hostnames
of 2 domains in /etc/hosts, what results in a fix on one domain,
another domain on the same machine was not affected and the error stays
as bevor.
I Tryed out, to fix my /var/named/my.stupid.zone, were i found a
missconfiguration by redhat-config-bind. I fix the config, checked my
nameserver out and hes runnin fine with no errors, but the getadress
error stays as bevor and was not affected. I am not really sure, if my
dns is perfectly configured, but i get no errors there and funcionality
is given, expecting the getadress error by php.
Over that, i cannot see anybody, who has full fixed this problem , so
its a discussion worth, but where ?!
I thing, it makes sense, if the Developers, that does or maintain the
filesocket functions of php, has a deeper look in this Problem, even if
its not php based, but they will have a clear overview, of what happened
and maybe they can give us a hint. What about the sockets ?
I thing, it is any incompatibility btw. named and the network classes
of php, especaially php mail and file network structures or classes,
maybe sockets ?!
On RH8 there are no such errors. In any case, this costs lotsa time :(
...
------------------------------------------------------------------------
[2004-06-10 14:40:34] austinputman at hotmail dot com
I had the same problem as pat at mail dot rit dot edu using
fsockopen().
He/she uses:
fsockopen("http://www.php.net/";, 80, &$errno, &$errstr, 30);
But you shouldn't use 'http://' in the server name part. So use this
instead.
fsockopen("www.php.net", 80, &$errno, &$errstr, 30);
Maybe this will not solve everybodies problem, but it sure solved mine.
------------------------------------------------------------------------
[2004-05-26 21:45:26] jpipes1 at columbus dot rr dot com
We have this darn error occur once every few months; our site relies
heavily on fopen's to URL resources on our own servers (to separate
templates out...), and I have run into these darn errors with
absolutely no help from anyone on any forums. This error is NOT fixed.
It has to do with something that changed from 4.0.16 to 4.3.4 on Apache
1.3.27 running RedHat 9 too. Please somebody look into this problem.
Errors only happen once out of every, say, 20 times, and it always
issues the getaddrinfo failed warnings. Then, the warnings start to
happen more and more frequently, on code that has been unchanged in
months. Finally, a restart clears it and we go on for a few months til
another restart.
I'm not a C programmer or a Linux guru and I wouldn't know where to
start with debugging this stuff, but if someone could take a look at
it, it would be helpful. Navigating around these bug indexes is
driving me nuts...
Sounds like some sort of memory leak or something (i.e. the warnings
happening after quite some time, then more frequently until a
restart...)
------------------------------------------------------------------------
[2004-05-13 00:34:48] cosas at minovela dot com
i've just installed redhat 9, then the latest version of mysql, php and
apache, and i got the error when i tried to run my scripts...
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/11058
--
Edit this bug report at http://bugs.php.net/?id=11058&edit=1
