[quote=MyDogBuster;163633]GB4000 seems to be down again.[/quote]


Argh! I see that my cores are sleeping on port GB8000 also.

I had to unplug and plug back in a wireless router to get my kid's laptop to connect to the internet but that shouldn't have made a difference. I only unplugged and replugged the little black chord from the back of the router. I didn't mess with the modem or any other connections.

I'll go take a look at the servers and see if I can do anything. Have you tried that command that you always do that seems to work when my IP address changes?


Gary

[quote=IronBits;163609][B]If that is the case... [/B]
[B]Bismarck[/B] or [B]is prime![/B] has not picked up any work since I posted.
I assume because 'he/she/they' got their kicks/laughs and then were found out, they went away.
Didn't mean to crash their party... :grin:

No big deal, found another spot in my script to harden :smile:

Be interesting how the rest of the scripts/stats/database handle it... not a big issue, we'll script around the 'kiddies' :big grin:

A quick search for Boinc and Bismark show someone on Team China...
and it shows a Q6600 computer using Vista64...
[URL]http://boinc.bio.wzw.tum.de/boincsimap/show_user.php?userid=25765[/URL]

Don't know if it's the same person or not however... and to be fair, on another Boinc site, searching for Bismark shows the following

[code]
User Name Country Team
Bismark Ukraine Ukraine
Bismark Australia Australia
BISMARK Spain Spain
bismark International International
bismark Canada Canada
[/code]

Max is the only person coming in now, so will keep an eye out...[/quote]


BTW, the userid is Bismarck (with a "c"), not Bismark. Have you tried a search for Bismarck? That might narrow it down.

[quote]Have you tried that command that you always do that seems to work when my IP address changes?

[/quote]

The command just now worked. I always try that first. Something interesting, I do not have to do the flushdns on 32 bit machines, just 64 bitters. Seems the 32 bitters just take off when the problem is resolved. Another hidden asset in Willies software. What a guy. LOL

BTW, unplugging the router and replugging it would fix a service problem. Your problem could have been between the router and the cable modem.

Ahhhh, my BAD
Further research on Bismarck points to that one individual on Team China...
[url]http://stats.kwsn.net/user.php?proj=all&cpid=c5fed7f1fbcec10ca395d4d698353e4f[/url]
No harm, no foul
Hope he chimes in he wants to create a Team China in the database and then wants to join it :smile:

I can't get my clients to consistently connect to port GB8000. I've sent a PM to Max to take a look at the server. I tried stopping and restarting both the server and the clients with no luck. Sometimes a couple of them will run for a little while but then they will stop again. There appears to be no "flushdns" command for Linux. Does anyone have any thoughts along those lines?

If you're wanting to run the 6k drive on this port, you might wait until late Monday or Max gives the word that the server is working OK.


Gary

Because the Server is on your internal LAN, you should be able to just use the internal network IP address in your configs. I do here :wink:
Let's say you have
192.168.0.1 as your gateway
192.168.0.2 as the ip on your server running the llrnet servers

edit your config file and use server = 192.168.0.2

Your server should be using a fixed ip address within your LAN anyways...

Hi all,

It turns out the G8000 server had crashed and needed to be restarted. However, it seems that the crashed copy of the server somehow refused to release its socket. netstat -a shows that port 8000 is bound for listening, yet I saw the crashed server terminal window with my own eyes and exited it. :huh:

David, do you have any idea what's happening? Usually when I restart a server the "cannot bind to port" error clears after a few minutes (possibly due to exactly when users are hitting the port, as you'd previously theorized), but this time it looks like something a little "bigger".

Anyway, as far as everyone else is concerned, the upshot of this is that I couldn't restart the server just yet. Stay tuned, though, as I'll try periodically. :smile:

Max :smile:

[quote=IronBits;163646]Because the Server is on your internal LAN, you should be able to just use the internal network IP address in your configs. I do here :wink:
Let's say you have
192.168.0.1 as your gateway
192.168.0.2 as the ip on your server running the llrnet servers

edit your config file and use server = 192.168.0.2

Your server should be using a fixed ip address within your LAN anyways...[/quote]
In fact, we *do* use fixed IPs for all of Gary's dedicated crunch machines, one of which is running all the servers. :smile:

Gary, as David said--whenever you have a client within your network running one of the nplb-gb1.no-ip.org servers, you can configure the client to say 192.168.2.100 instead. That's the *internal* IP address of the server and it will be a much more direct connection that will never cut off when any No-IP things have to change. :smile: (Note that you can't do this on your laptop, since then you wouldn't be able to connect to the server when away from your home network.)

You have to reboot the server if the port has hung after a crash.
You might want to try using an Intel Server NIC and disable the onboard motherboard NICs.
Also, if you have two onboard NICs, use the one and see if it behaves better.

[quote=IronBits;163707]You have to reboot the server if the port has hung after a crash.
You might want to try using an Intel Server NIC and disable the onboard motherboard NICs.
Also, if you have two onboard NICs, use the one and see if it behaves better.[/quote]
The only onboard NIC is the one on the motherboard, so not much of a choice there. Also, even if we did have more than one NIC installed I wouldn't be able to mess with any of that stuff from here, since any changes to NIC configuration would potentially mess up the SSH link that forms my only connection to that machine. :wink:

Anyway, I'll see if I can find out which prime-search appliations Gary's got running on that machine right now and, if they're easy enough to re-start up from here, try rebooting it remotely. :smile: (Don't worry Gary, I won't even try it unless I'm reasonably sure that I can get everything up and running again so that you'll hardly notice anything happened. :smile;)

[quote=mdettweiler;163708]The only onboard NIC is the one on the motherboard, so not much of a choice there. Also, even if we did have more than one NIC installed I wouldn't be able to mess with any of that stuff from here, since any changes to NIC configuration would potentially mess up the SSH link that forms my only connection to that machine. :wink:

Anyway, I'll see if I can find out which prime-search appliations Gary's got running on that machine right now and, if they're easy enough to re-start up from here, try rebooting it remotely. :smile: (Don't worry Gary, I won't even try it unless I'm reasonably sure that I can get everything up and running again so that you'll hardly notice anything happened. :smile;)[/quote]
OH MAN! I just figured out what happened. :rolleyes: When I tried logging on to the server's "terminal session" (as opposed to the session it gives you when you log on through VNC), lo and behold--there was a copy of the G8000 LLRnet server that had been running all along! No wonder port 8000 was already tied up by something--it was tied up by the G8000 LLRnet server which Gary had already restarted! :smile:

Gary, in the future, when you restart servers on crunchford could you possibly log into the machine via VNC, and then restart the server from there? Otherwise I can't see the restarted server's terminal window, and I think it's not even running. Thus I kept trying to restart it over on the VNC session, not realizing that it was already up and running on the console session and that that was what was hogging the port. (That would also explain why results have kept coming in for that port even after I thought the server went down. :wink:)

Okay, long story short: turns out the crashed server hadn't hung on the port after all. A new server was running the whole time! :smile:

I'll go and get the server moved over to the VNC session now so I can see it better, and get it into the while loop in case of crashes. :smile: