Heavy CPU usage after switch over

Seight · Post by **Seight** » Tue May 28, 2002 3:03 pm

I'm running a leaf bot on a large botnet and recently moved it to a new box to run from. I've noticed that after linking to the hub, downloading the userfile (500kb compressed) and then switching over to the new userfile, it simply lags - as in not responding to any command. CPU usage on the shell shows about 70% load at that time. After several minutes, it timeouts from the hub and try linking again only to repeat the whole process.
Now, this only happens when the bot is connected to a server. When I link it to the hub while not connected to any server (sometimes by just letting it try to connect to a fake one), everything works fine and I can connect it back to IRC.
This is a problem which is experienced with several of the other leaf bots - a long hang time after "Userlist transfer complete; switched over." but most other bots recover after a while, I'm guessing due to stronger CPUs.
Question is, why is this long delay or 'hang' even happens? and why only when connected to a server? when offline not even a second of lag is experienced.

Appreciate any feedback.

Shocky · Post by **Shocky** » Tue May 28, 2002 4:32 pm

Possibly it's a DNS issue.. Often if they have there DNS servers configured wrong, programs will just 'hang' or wait while trying to get an answer. Eggdrop is not exception to this.

Also, did you recompile (to make sure they are using the same libs)

Petersen · Post by **Petersen** » Tue May 28, 2002 4:44 pm

eggdrop does not hang on dns timeouts. ever since 1.6.0, the dns module has provided asyncronous dns lookups, thus meaning that the main loop is always running.

Shocky · Post by **Shocky** » Tue May 28, 2002 10:38 pm

Still does on my box from time to time with v 1.6.4, resetting bind every once in awhile fixes it.

Seight · Post by **Seight** » Tue May 28, 2002 11:49 pm

I don't think it's either of the things you've mentioned. First of all, where does DNS'ing fit in this problem? The bot is already connected to a server, running fine, just when linking and finishing getting userfile does this 'hang-time' occur. Secondly, I've got bots running on other networks from a copied eggdrop dir of the the first one (trouble one...) and they appear to be linking fine. Perhaps because their channels are less crowded (first bot is on the channel with the most users).
Anyone else with suggestions?

Shocky · Post by **Shocky** » Wed May 29, 2002 3:01 am

When a bot links to another bot.. It does a NSLOOKUP on the incoming connection.. It also polls the IDENT of the connection. For that matter, when ANY type of telnet comes in an NSLOOKUP and IDENT is performed.. From the same shell, telnet to the bot, and see.

Seight · Post by **Seight** » Wed May 29, 2002 9:27 am

...That still doesn't explain why it only happens when not connected to a server.

ppslim · Post by **ppslim** » Wed May 29, 2002 10:27 am

It does.

There has been an issue with eggdrop, hanging during identd requests, while the bot it not connected to a server, or sat as a limbo bot.

I have reported this I beleive twice in the past, where not even a single reply was made.

Seight · Post by **Seight** » Wed May 29, 2002 11:15 am

err.. meant - only happens when _connected_ to a server. When the bot is offline and getting the userfile then there's no lag after it switches over.
Again, when the bot is already connected (not necessarily immediately after connecting to a server) then it lags for a long period of time after getting the usefile, usually resulting in a timeout from the hub.

ppslim · Post by **ppslim** » Thu May 30, 2002 7:55 am

I sugest the following.

Connect to the partyline, and initate the transfer, so that the bot will lagg.

Once the bot is lagging heavily, do a ".dccstat". You should paste the reply of a DCCSTAT here on the forum, making sure you state this is when the bot is lagged (see below).

Next, you should totaly restart the bot, so there is a fresh working copy of the code in memory, and no memory leaks are occuring.

On the partyline, itiaite the link and userfile transfer, so that it should complete without fail or lagging. Then do a ".dccstat" as fast as you can, so to try and catch it while the transfer is in progress. If you can't get it fast enough, this step should be left out, as it's not needed as much.

The output of the first DCCSTAT, will tell us, what the bot is doing in the transfer state, and where it is stuck.

Seight · Post by **Seight** » Thu May 30, 2002 12:19 pm

I seem to have not explained myself clear enough.
The problem is not in the transfer itself and I've already confiremed that by doing .dccstat repeatedly while downloading. The 500kb compressed userfile is being transffered successfully. Here's is a sample log: (bot and channel names are fake)

Code: Select all

[13:06] Received challenge from HubX... sending response ...
[13:06] Linked to HubX.
*** Linked to HubX
[13:06] Downloading user file from HubX
[13:07] Ignored masks for channel(s): #channel1 #channel2
[13:07] Userfile loaded, unpacking...
[13:07] Userlist transfer complete; switched over.

This is the part where the bot queues all dcc commands I issue into memory so even .dccstat won't work and it will only perform my commands after it timeouts from the hub. So it hangs like this while _still_ performing its binds (meaning I can see putlog response from the loaded scripts and also mode changes in channel) then after a while this happens:

Code: Select all

[13:15] Ping timeout: HubX
*** Ping timeout: HubX (lost 76 bots and 11 users)
[13:15] (Userlist download aborted.)
[13:16] Received challenge from HubX... sending response ...
[13:16] Linked to HubX.
[13:16] Downloading user file from HubX
[13:17] Ignored masks for channel(s): #channel1 #channel2
[13:17] Userfile loaded, unpacking..
[13:17] Userlist transfer complete; switched over.

This cycle can go on for hours until it finally gets it right without timing out from the hub.
I will stress it again: This only happens when the bot is connected to an IRC server. When it's not connected and linking then there isn't even a single second of hang - and that is the weird part.
Also, I'd like to add that I've tried transfering the userfile without using the compress module and there isn't any difference, simply the d/l process takes a bit longer which is expected but hang time still occurs after switch-over.

ppslim · Post by **ppslim** » Thu May 30, 2002 12:50 pm

And as you made even clearer then, it happens just after it transfers the userfile.

Maybe, allthough it says it is complete, it is still clearing up, and performing others tasks that are not apparent, as no messages get posted.

As soon as it hangs, a ".dccstat" could still give information about connections that are hanging.

Seight · Post by **Seight** » Fri May 31, 2002 3:29 am

Actually I've screened out putlog messages as this is not a direct paste - They still occur. Bot is welcoming users and performs its binds. And no, .dccstat doesn't work or any other dcc command for that matter. They are queued in memory and only get executed when the bot times out from the hub.

ppslim · Post by **ppslim** » Fri May 31, 2002 7:11 am

I would sugest a debug compile, and force a core dump when it freezes.

Unless we know where the exact freeze is, there is no way we can fix it.