my linode server have a uptime of 68days!! please, I need to see so far my server can go..

[sorry about this, but I needed say that,.. ]

Is it okay to reboot after 69days ?

What if the thing from twilight zone starts to rip at the outside of your server. can Caker reboot the machine to dislodge the thing?

Actually, I think there's a good idea in here somewhere... How about a feature where you pay to fake out your uptime?

How's $1 for a 10 day increase in your uptime sound?

-Chris

I'm sure a psychologist can have a field-day with this obsession a lot of people have with uptimes.

Isn't a less-buggy, more-secure, faster-performing new kernel better than having a long uptime?

And the great thing about the 2.6 UML kernels is: netcraft can't figure out your uptime. (Or even the OS, for that matter.)

How does netcraft work, anyway?

Long uptimes are a Bad Thing. How many times in those past 68 days have you changed a config file? Have you? Can you guarantee if the box rebooted that it would actually reboot? Regular maintnence/reboot times are part of a good system maintenence strategy.

On another note, it is very much possible to do all the upgrades you need except for kernel upgrades all without rebooting. A new install of Apache, and whatever else. My uptime may be pretty hefty, but I've already restarted my Apache server once today for a config change. If you don't need any kernel upgrades, you can go as long as you want without a reboot. Sadly, some people reboot their boxes for upgrades that don't even require a reboot. It can be a good thing though to test to make sure your init scripts are setup correctly, etc, so when your box does go down unplanned, it's back up in a timely manner.

I think the unplanned reboot problem was Overlord's point. Any change to a critical service requires a reboot to confirm that said service will come back up during boot. Even if you haven't changed any config files, you should still confirm that the new executables process the existing config data correctly.

_________________
/ Peter

Apparently they make HTTP requests to your site, and then dissect the TCP packets sent back from your server.

First, they match the characteristics of your packets against some sort of OS fingerprint (like what nmap does) to figure out your OS.

Then they look at the "TCP timestamp" option enclosed within the TCP packet your server returns. This timestamp gets incremented over time (i.e. TCP timestamp is roughly a function of uptime), so if they make separate HTTP requests to your site over a few days / weeks, they can plot how your server's TCP timestamp is being incremented over that period.

Each OS has its own way of incrementing the timestamp (i.e. for each OS, the function of timestamp against uptime is different). Now if they combine their knowledge of what your OS is with what they've gathered about how your TCP timestamp changes over time, they'll be able to figure out your uptime.

The gory details are in this monumental BugTraq mail.

With a 2.6 UML kernel, I guess its network characteristics are so radically different from regular Linux kernels that netcraft just flags the OS as "unknown". Without an ID on your operating system, they won't be able to deduce uptime.

Odd, because I tested netcraft against a number of Linodes running 2.6, and it came back with Linux every time.

-Chris

Netcraft chooses not to figure out uptime for Linux 2.6 because the kernel internal clock rate was increased from 100 Hz in 2.4 to 1kHz in 2.6 (for Intel 32 bit architecture). The 32 bit TCP timestamp now rolls over at 49.7 days, instead of 497 days, making the deduced uptime values all but meaningless.

_________________
/ Peter

Thanks for clearing that up.

49.7 days is not a good figure. It gives Linux some sort of similarity to Windows 95.

Well, if he's really worried about that, then it might be worth the time to setup a planned downtime to test everything and make sure it'll all work on a reboot.