Author Topic: Host lookup errors (Read 8635 times)

Dabaron · « **on:** April 05, 2009, 08:00:00 am »

I seem to be getting an error at random times on all bots that I have upgrade to BeBot 6. All the ones getting the error are on 6.2, I have a few that are still running 4.x because I've never gotten around to upgrading them and they don't seem to be throwing same error.

Error:
Warning: socket_connect(): Host lookup failed [-10002]: Host name lookup failure in /bots/BeBot/main/14_Tools.php on line 160

I would think that error would only throw on calls to FC roster or something but doesn't seem to be the case. I have even seen it get thrown when the only thing that appears to be happening is regular chat.

Any ideas?

Karsta · « **Reply #1 on:** April 05, 2009, 05:30:37 pm »

I have been getting this same message since last patch and bot has been very slow often.

Sabkor · « **Reply #2 on:** April 05, 2009, 10:51:40 pm »

I haven't looked to see if could fix it, but it's due to tower attacks. When there is a tower attack, it looks up the attacker's details and that is what is timing out. On my bot, I get that message, and it disconnects from IRC as well, due to the fact that the bot pauses for a long time when timing out on IP operations like those.

Dabaron · « **Reply #3 on:** April 07, 2009, 07:12:10 am »

Anyone looked at this one yet? I haven't been able to figure it out based on info from Sabkor.

Khalem · « **Reply #4 on:** April 07, 2009, 11:50:32 am »

It's evident that something is causing the bot to "hang" and I've seen it occuring myself. However I'm not sure that the warning you see is related as I fail to see how that code is holding up the bot in any way unless the actual creation of the socket is taking forever.

Code: [Select]

	function get_site_data($url, $strip_headers = 0, $server_timeout = 5, $read_timeout = 10, $proxy = '')
	{
		$get_url = parse_url($url);

		// Check to see if we're using a proxy, and get the IP address for the target host.
		if (!empty($proxy))
		{
			$proxy_address = explode(":", $proxy);
			$address = gethostbyname($proxy_address[0]);
			$service_port = $proxy_address[1];
		}
		else
		{
			$address = gethostbyname($get_url['host']);

			/* Get the port for the WWW service. */
			$service_port = getservbyname('www', 'tcp');
		}

		/* Create a TCP/IP socket. */
		$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);

		// Check to see if the socket failed to create.
		if ($socket === false) {
			$return["error"] = true;
			$return["errordesc"] = "Socket failed to create.";
			$return["content"] = socket_strerror(socket_last_error());
			return $return;
		}

		$connect_result = socket_connect($socket, $address, $service_port);

Only way i can think of to find out is to add debug output, but that would likely create a large amount of output making it hard to find since it happens only occationaly.

You could change the function to this and see if you start getting gethostbyname errors:

Code: [Select]

	/*
	Gets the data from a URL
	*/
	function get_site_data($url, $strip_headers = 0, $server_timeout = 5, $read_timeout = 10, $proxy = '')
	{
		$get_url = parse_url($url);

		// Check to see if we're using a proxy, and get the IP address for the target host.
		if (!empty($proxy))
		{
			$proxy_address = explode(":", $proxy);
			$address = gethostbyname($proxy_address[0]);
			$service_port = $proxy_address[1];
		}
		else
		{
			$address = gethostbyname($get_url['host']);
			if ($address == $get_url['host'])
			{
				$return["error"] = true;
				$return["errordesc"] = "gethostbyname failed to lookup IP.";
				$return["content"] = $get_url['host'];
				return $return;
			}

			/* Get the port for the WWW service. */
			//$service_port = getservbyname('www', 'tcp');
			$service_port = '80';
		}

		/* Create a TCP/IP socket. */
		$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);

		// Check to see if the socket failed to create.
		if ($socket === false) {
			$return["error"] = true;
			$return["errordesc"] = "Socket failed to create.";
			$return["content"] = socket_strerror(socket_last_error());
			return $return;
		}

		$connect_result = socket_connect($socket, $address, $service_port);

Sabkor · « **Reply #5 on:** April 07, 2009, 03:38:23 pm »

Just to add a little more information to this, I took a look at my logs today, and I'm not getting the exact same error as the above people are. Same results, but not the same error. Here's the error I'm getting.

Warning: socket_connect(): unable to connect [110]: Connection timed out in /home/jason/bots/BeBot/main/14_Tools.php on line 164

Happens (depending on tower attacks) something like 10 times a day.

Khalem · « **Reply #6 on:** April 07, 2009, 05:05:34 pm »

It would appear that gethostbyname has a timeout of 20+ seconds if it fails to lookup for any given reason. The modified code i pasted should prevent the code from continuing to try and open the connection which might cause more delays.

I'm not quite sure how to best handle this, but i suspect enabling the use of curl might sidestep this problem.

Alternatively i envision having to add a resolver cache of some sort, especially given we will mostly keep looking up the same entries most of the time.

Khalem · « **Reply #7 on:** April 21, 2009, 06:40:27 pm »

I finally got around to think a bit about this, and It's not really all that strange that we are seeing this kind of problem.

Basically, whenever there is a tower attack occuring, there is anywhere from a few hundred to several thousand bots that at the same time will do a lookup.

The only solution i can see is that we stop doing lookups whenever people are doing tower attacks. It sucks, but i don't really see another way. We are simply killing the webservers with all the bots doing lookups. I'm actually suprised no one has complained about this from either Funcom or Auno.

Alternatively, and that only solves the bot hanging up issue, is to lower the timeout dramatically which means we will basically fail to get the information from the server anyways, while still causing server load.

Wolfbiter · « **Reply #8 on:** April 22, 2009, 01:06:33 am »

Doesn't lookup come with a noupdate variable anymore? you know.. where you can tell it only to use local db and not connect to a page.
Just tell tower script never to fetch from site, just local db and problem solved...

Khalem · « **Reply #9 on:** April 22, 2009, 06:58:04 am »

Well, that would in 90-98% of the cases give you either no level information or incorrect level information. So we might just as well just disable the lookup entirely.

Khalem · « **Reply #10 on:** April 22, 2009, 06:09:40 pm »

I've contacted Means about the issue and the possibility of having the notices sent out include the info people want, or alternatively albeit unlikely, allow whois lookups from the chatserver. He's going to run it past the coders and we'll see what comes out of it.

In the meantime, i would suggest just disabling the tower attack module.

Alternatively as Wolfbiter suggested change the following code in the module

Code: [Select]

$player = $this -> bot -> core("whois") -> lookup($infos["off_player"]);

to

Code: [Select]

$player = $this -> bot -> core("whois") -> lookup($infos["off_player"], TRUE);

Code: [Select]

$who = $this -> bot -> core("whois") -> lookup($attacker);

to

Code: [Select]

$who = $this -> bot -> core("whois") -> lookup($attacker, TRUE);

Sabkor · « **Reply #11 on:** April 22, 2009, 07:08:35 pm »

Awesome work, thanks Khalem.

Author Topic: Host lookup errors (Read 8635 times)

Dabaron

Host lookup errors

Karsta

Re: Host lookup errors

Sabkor

Re: Host lookup errors

Dabaron

Re: Host lookup errors

Khalem

Re: Host lookup errors

Sabkor

Re: Host lookup errors

Khalem

Re: Host lookup errors

Khalem

Re: Host lookup errors

Wolfbiter

Re: Host lookup errors

Khalem

Re: Host lookup errors

Khalem

Re: Host lookup errors

Sabkor

Re: Host lookup errors