Automatic updating problems

[Heri]

Hello Linux gurus,

I am running SuSE Linux Ver. 8.0 and have never been successful to get automatic updating to work although the autoupdate.cfg file has a 1 in it. Accordingly, I always end up downloading any new releases manually. Last summer the PC ran 1 month for naught while I was away.

The error.log file shows endless entries of download attempts where the received file length was only xyz and should have been 5087530 (as per the last update).

Any help or suggestions would be appreciated.

Thank you for taking the time to reply.

Heri Riesbeck

[Brian the Fist]

That error indicates a timeout while downloading the update. How long did you wait before manually updating? Usually during the first few hours our bandwidth is tied up with people grabbing the update but after a few hours it subsides and should be successful. Try waiting 6-8 hours after the update next time and it should be more successful and grabbing the update. Also what kind of connection do you have, dial-up or hi-speed?

[Heri]

Thank you for your reply.

I updated about 24 hours after the new version was published. Automatic updating has never worked here and it is unfortunate that it would not do any work if I do not babysit it.

I am on a cable connection albeit the Rogers Lite version which is perhaps comparable to 2 channels of ISDN. This ought to be sufficiently fast-IMHO. I had Rogers check out the line but they tell me that it does not drop any packets.

Furthermore, I am behind a 'home appliance' firewall. Again this should not matter.

Your program is compiled for Redhat. I am running SuSE. Does it matter - I do not know. Perhaps the download/autoupdate script is not compatible with SuSE. It is a perplexing situation.

Thank you again for taking time to look into it.

Finally, Happy New Year to you and yours.

Heri Riesbeck

[Brian the Fist]

It is likely a networking problem, not an OS problem. Where in the world are you exactly? What kind of ping times do you get to our server ftp.mshri.on.ca?

[Heri]

I can't ping ftp.mshri.on.ca Is it a pingable host?

I am located in Ottawa. I pinged the Mt. Sinai Hospital and got great returns - avg. 32ms.

Heri Riesbeck

[Brian the Fist]

That sound very odd to me, it should be pingable I think, yes. Try a traceroute and see where it gets stuck - maybe its just a temporary problem that we have no control over.
Anyways I can ping it just fine right now.

[Pascal]

Perhaps this may be interesting to you, Howard. I'm from Germany, using a ADSL connection (768kBit/s down, 128 kBit/s up).
I never used the autoupdate function, but it did work just below two hours after the presentation of the update. ;)

[Heri]

Her is the trace to the ftp host:
traceroute to ftp.mshri.on.ca (192.197.250.74), 30 hops max, 40 byte packets
1 192.168.2.1 (192.168.2.1) 2 ms 1 ms 1 ms
2 10.49.48.1 (10.49.48.1) 7 ms 8 ms 14 ms
3 gw03.flfrd.phub.net.cable.rogers.com (66.185.90.241) 8 ms 8 ms 8 ms
4 * * *
5 gw01.mtnk.phub.net.cable.rogers.com (66.185.82.125) 13 ms 12 ms 12 ms
6 gw02.wlfdle.phub.net.cable.rogers.com (66.185.80.149) 14 ms 13 ms 14 ms
7 dcr1-so-3-1-0.NewYork.cw.net (206.24.207.85) 37 ms 36 ms 36 ms
8 dcr2-loopback.NewYork.cw.net (206.24.194.100) 36 ms 49 ms 36 ms
9 144.232.9.117 (144.232.9.117) 50 ms 37 ms 36 ms
10 sl-bb25-nyc-10-0.sprintlink.net (144.232.13.182) 36 ms 37 ms 36 ms
11 sl-bb20-rly-14-0.sprintlink.net (144.232.18.253) 39 ms 38 ms 38 ms
12 sl-bb24-rly-9-0.sprintlink.net (144.232.14.122) 252 ms 214 ms 223 ms
13 sl-gw21-rly-9-0.sprintlink.net (144.232.14.54) 38 ms 39 ms 41 ms
14 sl-browing-11-0.sprintlink.net (160.81.98.2) 39 ms 39 ms 38 ms
15 P4-2.c0.wash.broadwing.net (216.140.8.1) 42 ms 41 ms 40 ms
16 216.140.8.102 (216.140.8.102) 42 ms 41 ms 43 ms
17 216.140.10.194 (216.140.10.194) 41 ms 42 ms 43 ms
18 67.96.116.138 (67.96.116.138) 44 ms 32 ms 31 ms
19 142.46.4.2 (142.46.4.2) 30 ms 31 ms 30 ms
20 tor-tierb.onet.on.ca (130.185.4.158) 31 ms 33 ms 32 ms
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *

It appears that it is getting stuck in the onet.

Heri

[DB7654321]

I'm also unable to ping ftp.mshri.on.ca...Perhaps ping is firewalled out for part of the internet? However, I was able to download the update. There was some issue with my proxy caching the server.status page, but, after manually refreshing it from Mozilla, the update went through.

traceroute:

traceroute to ftp.mshri.on.ca (192.197.250.74), 30 hops max, 38 byte packets
1 linuxserver (192.168.1.1) 1.001 ms 0.478 ms 0.388 ms
2 chcgil2-ar7-4-3-184-001.chcgil2.dsl-verizon.net (4.3.184.1) 123.717 ms 21.902 ms 20.557 ms
3 4.25.53.177 (4.25.53.177) 25.044 ms 26.979 ms 21.482 ms
4 p5-0.chcgil2-cr7.bbnplanet.net (4.24.223.5) 22.208 ms 24.496 ms 26.426 ms
5 so-3-3-0.chcgil2-br1.bbnplanet.net (4.24.8.105) 24.964 ms 36.594 ms 21.385 ms
6 so-0-0-0.chcgil3-hcr1.bbnplanet.net (4.0.1.181) 23.229 ms 27.237 ms 26.706 ms
7 p2-0.xchcgil13-teleglobe.bbnplanet.net (4.24.7.74) 29.527 ms 20.607 ms 20.619 ms
8 if-4-2.core1.Chicago3.teleglobe.net (216.6.16.33) 27.978 ms 21.436 ms 21.382 ms
9 if-7-0.core2.Chicago3.Teleglobe.net (207.45.220.46) 23.701 ms 21.351 ms 23.376 ms
10 if-9-0.core2.Scarborough.Teleglobe.net (207.45.222.181) 48.441 ms 49.002 ms 47.917 ms
11 if-4-0.core1.Scarborough.Teleglobe.net (207.45.222.205) 50.327 ms 46.727 ms 47.012 ms
12 if-8-0.core1.Toronto2.Teleglobe.net (64.86.80.242) 52.993 ms 49.079 ms 48.241 ms
13 ix-3-2.core1.Toronto2.Teleglobe.net (64.86.84.202) 48.091 ms 46.956 ms 47.707 ms
14 tor-tierb.onet.on.ca (130.185.4.158) 48.328 ms 47.638 ms 46.915 ms
15 * * *
16 * * *
17 * * *
18 * * *

[Brian the Fist]

Yup its normal for the tracert to stop there, and the ping to be blocked.
I'm not sure what else to tell you, except read over the README file carefully and ensure you have followed the directions properly.
The only other possiblity is you may have a transparent proxy which is caching files and thus not acknowledging the update until it flushes its cache. This is a common problem for some users.

[Mikus]

The previous three protein switchovers, automatic update did not work for me -- I ended up doing a manual download and install.

So this time around I decided to do something different -- I erased file 'autoupdate.cfg' (which had a single line containing the digit 1) from the same directory as the client.

Result: The client uploaded its accumulated filesets, downloaded the new protein, and went to work -- all without any intervention on my part.

mikus (using Intel client on Linux SuSE 8.0)

[AMD_is_logical]

One of my computers also runs SuSE Linux Ver. 8.0, and I've seen the same sort of thing Heri describes. The latest update wasn't too bad, probably because it wasn't too big. But previous updates have often taken quite a number of tries, although it would work eventually. I am in NC and have ADSL.

I have also seen my Win2k machine struggle the same way, but not as much. I'm sure it doesn't help that I have several computers trying to update at the same time over the same ADSL line.

I suspect that having a machine download the update 10 times from a heavily overloaded server is probably not the most efficient way of doing things. Perhaps I should restart the client in no-net mode before the update, and let it update after the load has died down? I suppose I could do something like that.

It would also be nice if the downloading was more robust, and could resume downloading a file until it was finished. I find that downloading with a browser can be *much* more robust. I manually downloaded the latest distro on a SuSE 8.1 system during the high load time, and it must have stalled a dozen times. But it would always resume, and eventually it got the whole file.

[Brian the Fist]

Unfortunately I did not write the 'file downloading' code, it is part of a library, and I cannot easily change much of it.

However, if you have several machines, please have a look at the 'proxy dameon' on our Download page, it will help reduce your load.