OS reboot for long time

[Deepanpriyen]

Will there be any issue if os is not rebooted for more than a year????

[Patrick Wallek]

As long as your boot disks are OK and nothing catastrophic has happened, then there's no reason the system shouldn't reboot successfully.

I've had systems up for several years that rebooted without any problems.

[Bill Hassell]

Yes, HP-UX can run for several years without an issue and reboot just fine.

HOWEVER:

-- If you don't look at all the logs BEFORE you reboot...

-- If you don't run dmesg to see if there are some console error messages...

-- If you don't verify that your vg00 mirrors are still intact and actually have valid boot areas...

-- If you don't verify that you actually have vmunix stored in /stand...

-- If no root user has played with pvmove...

-- If you don't have a known-to-work Ignite backup of vg00...

You are at risk.

In other words, you can run for years without any vmunix or vmunix.prev, but the system will not reboot. If a newbie root user accidently copied a file on top of your boot disk, you need to repair it with mkboot. Again, you'll never know anything is wrong until you try to reboot.

So the number of years is not the problem. It is all the root user mistakes that may have been made long ago.

Whatever you do, do NOT reboot until you have run a successful Ignite backup, either tape or to your Ignite server.

[Matti_Kurkela]

If your OS version has no unpatched uptime-related bugs, then the system should keep working.

But in a system administration viewpoint, there are generally a few possible reasons why a system might have been running for more than a year without rebooting:

• the OS is supported, but so stable and mature that there has been no need to install any patches in a year (= good, but very rare)

• the OS is so old it's out of support, so no new patches have been released for it any more (sort of bad, but if it works and you have good backups and replacement hardware in store...)

• there are patches that should have been installed, but someone has not done that (obviously, that's bad)

• the patches actually have been installed, but the system has not been rebooted after patching to confirm that is still bootable with the patches installed (that's a very bad practice)

[Dennis Handly]

>but the system has not been rebooted after patching to confirm that is still bootable with the patches installed (that's a very bad practice)

I'm not sure how that can happen or why a reboot would be needed.

1) Kernel patches require a reboot.

2) It is isn't a kernel patch, why should a reboot matter?  (I suppose it could be a patch to some RC(1m) process.)

[Matti_Kurkela]

Yes, swinstall will generally try and force the system to reboot if it is required. But someone might install a set of patches using swinstall in interactive mode within a screen session or similar, and then forget to confirm the reboot request. As long as the screen session remains, the system will wait for confirmation to reboot.

I think I encountered a situation like that once: as I recall, it was the result of a crisis situation and someone working for more than 24h straight, and was remedied as soon as practical. It was just a honest mistake. But it is technically possible for someone to actually do that intentionally, although it is a very bad idea.

Of course, when checking the patch states more carefully, in that situation you would see that the new patches would be in state "installed" rather than "configured" as expected, and would hopefully investigate further...