What happened with the update ?

[Mikus]

I've done two uploads since 2pm EDT. In both cases, after the upload, the client *continued*. Just to make sure, I just did a 'Q', and when I restarted the client (at 7pm EDT), it said "checking for new verision" but then IMMEDIATELY started
building structures.

My protein.trj is 2706269 bytes dated Aug 26. Wasn't there supposed to be an update today ?

mikus (using Linux client)

[Paratima]

There WAS an update today. The newest is processing a protein 111 thingies long instead of the other that was 53 thingies.

If you are still processing the 53, you got gypped and should apply for a refund. :)

...or perhaps do a manual update...

[bwkaz]

Is there anything useful in error.log?

[guru]

Not one single system auto updated. They even fail to manually update. The only way to update them so far has been to download and manually install the new files. This goes for my Solaris, Linux and Windows systems.

guru

[Mikus]

Originally posted by bwkaz
Is there anything useful in error.log?

Only the fact that the separator line with equal signs was never drawn for Sep 3.

[Mikus]

Originally posted by Paratima
There WAS an update today. The newest is processing a protein 111 thingies long instead of the other that was 53 thingies.

If you are still processing the 53, you got gypped and should apply for a refund. :)

...or perhaps do a manual update...

It was unconcernedly still processing the 53. So I stopped it, downloaded the whole package, and installed it manually.

Its now processing the 111. Whew.

Mikus

[Paratima]

This is just conjecture, mind you. :cool:

It appears that occasionally, a client will attempt to check for an update while the server is temporarily busy. It doesn't have to be busy long, a millisecond would do just fine. Instead of getting a "hold on a sec", it gets the digital equivalent of "push off". It goes ahead and dumps its buffers and continues as if all were well.

The chances of this happening are rare, timing-wise. However, it will continue to become more of a problem as more client machines are added to the project, just because.

[TheOtherPhil]

My farm also failed to auto update....9 clients needed manual attention :bang:

[gopher_yarrowzoo]

Ouch!... Thank God I don't have to spare processing power to crunch anything but Seti :D at least that works (kinda)

[Mikus]

Originally posted by Paratima
This is just conjecture, mind you. :cool:

It appears that occasionally, a client will attempt to check for an update while the server is temporarily busy. It doesn't have to be busy long, a millisecond would do just fine. Instead of getting a "hold on a sec", it gets the digital equivalent of "push off". It goes ahead and dumps its buffers and continues as if all were well.

It failed to update three times when the client reached a full fileset and uploaded that. It also failed to update when I manually stopped then started the client, this is when it is SUPPOSED to check for a new version.

That's four times. I sincerely doubt that the servers were busy on each occasion as you describe them, since the servers *were* able to upload filesets.

And as somebody else asked, there were no unusual entries in the error log. Usually, if the server is busy, the error log says so.

Mikus

[Brian the Fist]

As a matter of fact, the main server had network trouble immediately after the update, for several hours. I eventually settled for rebooting it and it seems to be okay since that. This is likely why some of you experienced troubles updating. Again, if you just would have left it alone it would have eventually updated once the server was back and healthy. We couldn't post a message about the problem on the web site as the whole web site and server was down.
If the problem happens again, we'll switch the NIC.
Sorry for any inconvenience

[Paratima]

Originally posted by Brian the Fist
Again, if you just would have left it alone it would have eventually updated once the server was back and healthy.I'm sure that that is true for many instances. Not always, however.

I was out of my office all day yesterday. Of 8 boxen on Win2K and 1 on Linux, all eventually updated automatically except 2 of the Win2K boxen. They were halted, not updated, with no indication in error.log as to why.

The client has different responses to different conditions of not being able to phone home. For instance, if the network is just plain unavailable, as in the CAT5 cable being unplugged, it just goes merrily back to work as if it were nonetted. Ditto, server busy, usually. However, sometimes it gets some indication back that makes it just plain stop running.

I don't know why this happens, but it seems as if a simple diagnostic could be built in to detect it. A lot of these errors don't seem to make it into error.log. :confused:

[Brian the Fist]

I certainly don't claim to be ready for any possible error that could go wrong, but I've tried to handle as many as I am able. If you can give me more specific details (which I know may be difficult) and if I am able to reproduce the problem, then I can go ahead and fix it, probably by just changing a line or two of code. Otherwise I'm pretty helpless as we do not have the resources to test for all possible (and impossible) problems ourselves. Networking is a very complex area with literally dozens of things that can and do go wrong..

[Paratima]

Cancel this post. I got new info to dig thru. I'll try to get you something better to go on. :)

[Mikus]

On the current protein change my computer did not auto-update, just like it did not auto-update on the previous protein change.

The recommendatiion then given was to let
the system keep running - that it would auto-update SOMETIME. But I have no desire to keep running with the old protein into the next day -- so I'm doing a manual download again.

mikus

[bwkaz]

This may be a dumb question, but you do have a file named "autoupdate.cfg" in the same directory as the client, with a single line in it -- "1" -- right?

[Mikus]

Originally posted by bwkaz
This may be a dumb question, but you do have a file named "autoupdate.cfg" in the same directory as the client, with a single line in it -- "1" -- right?
Right.

it *did* update automatically three proteins ago.

mikus

[DB7654321]

Neither of my Linux boxen (The Win2K box hasn't connected recently -- it's much slower) have received this update. When I ran ./foldtrajlite -f protein -n native -ut just a few minutes ago, it quickly passed over the 'Checking for newer versions...' thing.

[bwkaz]

Originally posted by Mikus
Right.

it *did* update automatically three proteins ago.

mikus Hmm, OK. Well, it was worth a shot...

I'm not sure of what else to try... :(

[Brian the Fist]

Always check your error.log for clues to why something may not have worked.

[Mikus]

Originally posted by Brian the Fist
Always check your error.log for clues to why something may not have worked.
Here's a clue for you:

- There *was* no error.log !!!

I do not know if it disappeared before I did those uploads which should have performed a download (in which case it may have been I myself that erased it -- I forget whether I did so or not) -- or it may have been erased (or never written) when the client should have been performing its automatic upload.

In any case, I now *do* have an error.log -- it starts with the timestamp when I first brought up the newest client (and contains only "timeouts" from those occasions when the client was ready to upload, but I had *not* established my dial connection to my ISP).

mikus