Solaris Machine Shut Down After 3737 Days of Uptime

An anonymous reader writes "After running uninterrupted for 3737 days, this humble Sun 280R server running Solaris 9 was shut down. At the time of making the video it was idle, the last service it had was removed sometime last year. A tribute video was made with some feelings about Sun, Solaris, the walk to the data center and freeing a machine from internet-slavery."

Comments

So what did it do all that time?

[cod3r_]

A *nix machine being idle for 3737 days is not all that interesting.

Re:So what did it do all that time?

[Anonymous Coward]

Somewhere at my last job, there was a Solaris 8 machine with over 4000 days uptime, that everybody hated to do anything with, but one person loved it and refused to migrate the last service that was still on it to something more modern.

Uptime is irrelevant for an individual server, anyway. If there's fail over (and there should be if uptime is important), take it down and update the kernel for security reasons, who cares?

Re:So what did it do all that time?

[crutchy]

If there's fail over (and there should be if uptime is important)

i agree... if you're responsible for a single server performing a mission critical function with no fail over, you may as well just fire yourself

Re:So what did it do all that time?

[h4rr4r]

Just get it in writing.
Been there done that, when it has to come down for hardware failure or something like that you can show you tried to get a backup machine, you tried to do things right.

Re:So what did it do all that time?

[kasperd]

mission critical function with no fail over

It is surprisingly hard to guarantee data integrity when doing a fail over.

If you want to guarantee a system keeps operating and maintains data integrity when a single computer fails, you need at least another three computers that are still running with no failures. There is a mathematical proof for this.

If you want to go lower than four computers, you have to make assumptions about how the failures behave. And if just one computer fails in a way that does not match your assumptions, the system will fail.

If you do decide to go with the four computers required to handle a single failure, the protocols to ensure they agree on the current state of your data are quite complicated. The protocols have to be non-deterministic. That's another proven fact. No matter how many machines you throw at the problem, a deterministic protocol cannot handle even a single failure.

You can get around the non-deterministic requirement if you make assumptions about the timing of communication. But you'd slow down the system unnecessarily because you'd have to wait for the maximum time you assumed packet delivery could take on every operation, and if the network was slower than you assumed, the system would fail.

Knowing how difficult fail over can be, it is no surprise that sometimes it is decided to not bother with it and instead hire an operator, who you assume can make everything be ok as long as you have backups plus spare hardware ready to put in production.

Oracle sucks.

[RocketRabbit]

I'd just like to leave this here. Yeah, I know Linux is great and everyfink, but Solaris is excellent and better in some ways. Oracle really ground my gears when they stopped supporting OpenSolaris and OpenIndiana is going nowhere fast.

RIP Sun.

Re:Oracle sucks.

[tnk1]

I don't think his comment suggested anything else. You should probably parse it like this:

(Oracle really ground my gears when they stopped supporting OpenSolaris) && (OpenIndiana is going nowhere fast)

Oracle support only applies to the Left Side of the statement. The point of the statement was to suggest that with support gone, and the only alternative to the supported version going nowhere, the Solaris world is completely Shit Out of Luck.

Re:Oracle sucks.

[ebno-10db]

VMS isn't a Unix

So I've heard, but I believe it is a "computer operating system". Hence I thought it was a more appropriate comparison than to a bicycle.

and I don't believe you can get ahold of VMS any more

Then into the memory hole!

The IBM mainframes are too expensive

For whom? To operations like banks, for whom downtime is incredibly expensive, they're still worth it. For me, an UltraSPARC like the 280R breaks the piggy bank. I get my x86 hardware from other people's castoffs.

and not open source

As you pointed out, OSS Solaris is toast.

What's your point exactly?

Umm, that some other OS's are/were at least as reliable as Solaris. Was I being that obtuse?

Last message in system log was . . .

[StefanJ]

. . . Mar 12 11:57:03 hedvig kernel:WILL I DREAM?

This is news?

[Fished]

I work at a Very Large Company (who must remain nameless.) We've got Solaris boxes that were last rebooted in the 90's. Yes. Really. Running Solaris 2.6, even.

Re:This is news?

[bobbied]

I work at a Very Large Company (who must remain nameless.) We've got Solaris boxes that were last rebooted in the 90's. Yes. Really. Running Solaris 2.6, even.

I am not surprised. I've seen Sparc/Solaris boxes run for very long times and even when not properly cared for have run times measured in months and years. I've had to shut down boxes to move them that had been running for 5 years. We where scared to death the disk drives would not spin back up after 2 days in the truck, but when we plugged them back in, they powered right back up. Sun built some SOLID hardware and produced a SOLID operating system.

Here's the real question...

[jayhawk88]

Did they power it back up again after shutting it off? Just to see?

Re:Uptime fetish

[guruevi]

You can get patches, even kernel patches without having to restart the system. That was one of it's selling points back in the day, some systems even allowed you to hot-swap or hot-upgrade CPU's and memory.

Re:in other news ...

[ebno-10db]

a slab of concrete has been found with an uptime of 3737 years

You exaggerate. The oldest concrete structure I know of is the dome of the Pantheon, and that's only been around for 1887 years. Time will tell if it was well built.

Re:Uptime fetish

[Anonymous Coward]

If you don't care, you don't understand history. And sadly, looking at your attitude and phrasing, I got a feeling you're older than I and should know it better.

That you understand it's not worthy of worship is a mark in your favor -- but not as big as you're hoping.

It's not fanboyism. It's from the old cult of service. From taking your limited resources on a system that costs more than your pension, and absolutely positively guaranteeing they were available to your userbase.

We didn't all have roundrobin DNS, sharding, clouds in the early 2000's.

Some of us had Sun's, BSD's, Vaxen, and other systems that might be missing security fixes, but that by and large were secure as long as you made sure nobody that didn't belong on it had an account.

Kernel and driver patches? It might be a performance boost, it might be a security patch. It might be a driver problem that could cause data loss, but only if you were running a certain service. A great admin can choose which are needed. A good admin knows they should apply them all

There's something to be said about rebooting machines -- just to make sure they'll still boot. But the best sysadmins didn't need to check -- they knew.

Uptime diferentiated us from our little brothers running windows, who couldn't even change network settings without a reboot. Who had to restart every 28 days or crash horribly. Who could be brought to a grinding halt with a single large ICMP request.

In short, uptime was an additional proxy variable for admin competence (given the presence of an unrooted box).

Yeah, any idiot could leave a system plugged into a UPS in a closet and have it come out OK. But if you didn't get cracked and filled with porn, you were doing something right.

Given elastic clouds, round robin DNS, volume licensing, SAS... it's very nearly cheaper to spin up a new image and run the install scripts than reboot these days.

I'm not convinced this makes modern sysadmin practices better -- just more resilient to single-host failure.

Just the other week we had a million dollar NAS go down for nearly 12 hours (during the week) while applying a kernel update to the cluster.

If you did that in 99 on a Unix system, you'd have probably been shot after the execs showed you out the door.

Somehow, the cult of service availability has been replaced with the cult of 'good enough'

Not a good thing!!!!

[onyxruby]

Last place I was at that had server admins that bragged about /years/ of uptime quickly turned into a discovery that we had thousands of servers that had not been patched in years. Only a few systems can patch the kernel without rebooting and those are the exception, not the rule. It turned into a six month project but in the end we were patching systems that were vulnerable to 5 year old exploits (mix of *nix and Windows).

I had to make the argument that server uptime meant jack, and to make it I put forward the argument that the only thing that mattered was /service/ uptime. Frankly it is the service that needs to be always available, not the server. This is why you have maintenance windows, for the explicit purpose of allowing a given system to patched and rebooted at a predictable time without interrupting services.

If your server is really that important it will have a fail over server for redundancy (SQL cluster, whatever). If your server isn't important enough to have a failover server for service redundancy that it isn't so important that you can't have a maintenance window. Think service, not server!

The only thing that matters is service availability.

Re:Uptime fetish

[Anonymous Coward]

The summary is misleading. It was acting as a backup server for it's own replacement.

My /. user number? I'm honored!

[Shag]

I know, I know, it's just a coincidence...