[Q] Autoupdate

Ok - the big last-minute question!

If I added autoupdate.cfg (containing the mandatory "1" no quotes) AFTER starting the foldit script - will it check for updates and download still, or do I need to restart all these clients?

I'm hoping it's not a single run-time check and go...

The ones on the clusters are easy - the ones spread around the house and hidden in cabinets and cupboards and out in the garage - ick! *please* tell me I'm not going to have to dig through several dozen machines to figure out which were updated and which weren't... ;)

(Linux Intel and Linux gcc clients, RH 7.1 and 7.2 primarily)

It checks for the presence of autoupdate.cfg only upond startup of the client. Sorry. If it is missing, you will be required to hit 'Y' to download the update, that is the only effect it has. If it is there, you don't have to hit 'y' and it will automatically download the update and install as long as it is digitally signed.

Eeeek! So I have to stop and restart them all. (running in quiet mode) - which means I need to find an excuse to bail on a few meetings today and drive across town. [pout]

For future updates - Is there a reason (I haven't thought through it much) not to make the check for the file basically right before your prompting?

Thanks!

Not really.. I just assumed most people would either put it there or not so I didn't think it would matter. I can change it for future versions but it won't help you now ;(

Never underestimate the stupidity of lusers - especially the technically savvy ones. ;)

I basically installed it, migrated it with a handle.txt in place, and then kicked it off. Then scurried around and installed it on everything I could get my hands on around the house and a few I couldn't (AV storage and RAIDs are in the attic crawlspace at the opposite end from the furnace - kinda tight fit, it's a deliberately stripped system, so upgrades require a terminal cable that I never got around to screwing in and leaving there)

After I did ALL of that, I read the readme, then scurried around a second time and dropped an autoupdate.cfg on the machines I couldn't scp to...

Don't know why I'm telling you all that - doesn't matter. First sentence says it all... ;)

Actually, if you are running them as a Windows service (not sure if you are) then the autoupdate.cfg is not needed, it is automatic.

Nope - all but one dual P3 are Linux-based. An even 50 running Mosix clustering under Linux 2.4.17 kernel, either AMD 1.4 Tbird or AMD XP1700 depending upon purchase date.

Another 25ish running varying versions of Linux doing various things off and on running on various processors, and not clustered.

Another 20 AMDs will be added to the cluster starting Tuesday - XP1800s.

Thanks, though!

Kinda :|ot|: - but...

I'm trying to be fairly gentle - I have 3Mbits up and down from here - so I'm pacing myself. If in the future autoupdate works for me and other farmers and you get slammed - how bandwidth sensitive are you? Should we be scripting our clusters to spread it out?

Another silly question - if I'm running in -qt and autoupdate isn't happening for me - will the client eventually stop trying to send now-worthless data and die? Or will my loads stay peaked forever?

If it eventually dies, life would be easier if I accidentally miss a machine or two. Load averages would tell me then if I missed it.

Well I got zapped by that autoupdate.cfg same as you!
Ran around Wednesday and plopped the file in my systems not knowing enough to stop and restart the clients.
After the new stuff was released, I found two systems runnig quiet mode were in tight loops 100% load and I'm guessing they were waiting for a y(es) input to install the update. They were like that for about an hour, so I'd bet the client never dies, just waits forever. I could not stop the client with a q input so I had to kill them and restart, then they updated ok. This is with win2000 not Linux but it's probably the same.
Live and learn;)

Rather than kill them, the trick there is to delete the trajfoldlite.lock file. It will then upload and update a few moments later. (from the readme file)

IF you are in quiet mode and don't have autoupdate.cfg it will wait forever for you to hit 'y' I believe, yes. But deleting the lock file will exit it gracefully. Again, it IS all in the readme, and I know people don't like reading docs but sometimes its helpful :p

To answer the bandwidth question, those techno-geeks amongst you who have been sniffing Distributed Folding traffic already know - the updates are grabbed from www.intel.com...

(They have lots of bandwidth, but if we get enough users, we still might be able to bring them down :D)

Aha! That explains the sub-5second update I saw from the one office machine I have on df... redundant 255Mbit connection meets redundant 255Mbit connection...

I guess my question wasn't covered in the readme -

Will my loads drop when it's sitting there waiting for the non-existant "y" - or is the loop obnoxiously tight hence running my load up to 1.0 and giving me no indication.

Ok - idea version .90b - I have managed HP Procurves handling all ports now (finally moved all my low-density stuff out) - so I need to reset my HPs' packet counters, wait a day or so, take a map of all the machines -> ports, log in and see who hasn't moved any (much) data across their port since my reset.

Ok, that's do-able. :crazy:

Not to pick a nit or anything but the readme I have goes:
To enable this feature ... create a text file in same dir as client named autoupdte.cfg with a 1 on a single line (PERIOD)
Next it says
If you change your mind remove file and it will reset next time you run it.
I'll take your word that when it's waiting for a y(es) it checks for the presence of the lock file to exit with grace, hopefully I won't have to find out:D