A good kick up the...er, a good re-start

[OFSO]

Me ol' PC, still running the OS that Dare Not Speak Its Name (but behind a WiMax firewall & having twice daily anti-virus scans) has been getting cranky over the past month. Little annoyances when printing (damn you, HP) or with Outlook Distress or runny software, all work-around-able but irritating.

Before going away last week I tried to put it into STBY. Wouldn't have any of it and hung half way, so I hit the power-off button and walked out. Lo and B., when I came home I turned it on and all the minor faults have gone.

Seems odd to me that this aspect of running complex software (or at least software based on the concept of a Registry) isn't mentioned more often. Or do grateful little mice* appear from nowhere and restore everything once it's turned off for
a few days ?

*Cf "The Tailor of Gloucester" by Beatrix Potter

[ExSp33db1rd]

OFSO recently my IT man suggested that I go for a "restart" - not a switch off and re-boot - three or four times in quick succession to repair .pst faults in my Outlook Distress mail programme. It has been suggested on another thread (TOP ? ) that I change my IT man - but his advice works ! Nothing lost.

[OFSO]

I'm now using Outlook Express Classic - paid-for version - no problems there. But I agree with your IT's man's suggestion.

Is my memory playing false or does at least one combat aircraft have a large "pull to system reboot" switch near to the pilot's hand ?

[rgbrock1]

Reboots are necessary in the Windoze world. Chrome OS, Apple's OS X and most Linux distros do not need reboots.

And as for larger servers: there is an OpenVMS server operating in the Netherlands which has not been rebooted in 26 years.

[admin]

Reboots are necessary in the Windoze world. Chrome OS, Apple's OS X and most Linux distros do not need reboots.

Don't know about that. I've had three or four kernel upgrades for my RHEL/CentOs systems in the last year, and a kernel upgrade always requires a reboot.

Alison

[rgbrock1]

Reboots are necessary in the Windoze world. Chrome OS, Apple's OS X and most Linux distros do not need reboots.

Don't know about that. I've had three or four kernel upgrades for my RHEL/CentOs systems in the last year, and a kernel upgrade always requires a reboot.

Alison

I've been working with Linux, of varying distros, for many years Alison and anytime a kernel is upgraded it does NOT require a reboot. Key word, however, is require.
You can very well plod along with the pre-patched kernel but any new functionality or bug fixes will not take effect until a reboot is performed. But it is very rare for anything in Linux to require a reboot.

[OFSO]

I second that. I have never rebooted my Mint computer. The Chromebook requires restarts to upgrade the software, but never needs rebooting of course. However, the Android slows down perhaps twice a year and a restart sorts it out. Windows ? As I've said, needs a kick up the drive now and then.

[admin]

I've been working with Linux, of varying distros, for many years Alison and anytime a kernel is upgraded it does NOT require a reboot. Key word, however, is require.

Rgb, to the best of my knowledge Red Hat/RHEL/CentOS do not patch their kernels for security reasons. I have been a CentOS user since it's first release back in 2005 or thereabouts. CentOS forked off Red Hat Enterprise Linux then, and has since rejoined it, in 2014. CentOS is an RPM based distribution, using repositories for updates.

When I run the YUM - "Software Update" function, it goes out and checks all the repos, for the latest versions of everything loaded, and down loads all newer modules, installs them, cleans up and if a new kernel calls for a reboot to activate the new version. It also deletes the previous Kernel crash dump, thus requiring KDump to be rebuilt.

Should a user wish to add extra functionality, as in new hardware support, then they have to re-compile the kernel with the added functionaility, and then reload it and then REBOOT to make the new functionality accessible.

Alison

PS. Please note RHEL and CentOS are not hobby distros, they are meant for serious business where security considerations are paramount.

[rgbrock1]

I've been working with Linux, of varying distros, for many years Alison and anytime a kernel is upgraded it does NOT require a reboot. Key word, however, is require.

Rgb, to the best of my knowledge Red Hat/RHEL/CentOS do not patch their kernels for security reasons. I have been a CentOS user since it's first release back in 2005 or thereabouts. CentOS forked off Red Hat Enterprise Linux then, and has since rejoined it, in 2014. CentOS is an RPM based distribution, using repositories for updates.

When I run the YUM - "Software Update" function, it goes out and checks all the repos, for the latest versions of everything loaded, and down loads all newer modules, installs them, cleans up and if a new kernel calls for a reboot to activate the new version. It also deletes the previous Kernel crash dump, thus requiring KDump to be rebuilt.

Should a user wish to add extra functionality, as in new hardware support, then they have to re-compile the kernel with the added functionaility, and then reload it and then REBOOT to make the new functionality accessible.

Alison

Alison,

I've worked with RHEL extensively in the past. (And with SLES - SuSE Linux Enterprise Server - also RPM-based) I agree with everything you wrote as far as a reboot being necessary to activate a newer, or patched, version of the Linux kernel. What I was trying to say is: unlike certain other operating systems it is not required to reboot Linux after updating any part of the OS. You simply plod along with what you already have.

And, yes, I know RHEL is not for "hobbyists". I've set up RHEL clusters in the past!

[admin]

What I was trying to say is: unlike certain other operating systems it is not required to reboot Linux after updating any part of the OS. You simply plod along with what you already have.

Now I'm confused. If the intention is to "plod along with what you already have" then why upgrade in the first place? If the release notes indicate some security vulnerability which is fixable by an upgrade, then given the nature of the Internet these days one would be silly not to upgrade.

That is unless it is not an online system but an internal system where external security may not be an issue. I can see where you are coming from if the system is acting as a file or data server alone, or as part of an internal cluster providing redundant or shared resources.

Alison

[rgbrock1]

What I was trying to say is: unlike certain other operating systems it is not required to reboot Linux after updating any part of the OS. You simply plod along with what you already have.

Now I'm confused. If the intention is to "plod along with what you already have" then why upgrade in the first place? If the release notes indicate some security vulnerability which is fixable by an upgrade, then given the nature of the Internet these days one would be silly not to upgrade.

That is unless it is not an online system but an internal system where external security may not be an issue. I can see where you are coming from if the system is acting as a file or data server alone, or as part of an internal cluster providing redundant or shared resources.

Alison

One may be at a point during the work day where an upgrade/update can be kicked off but it isn't convenient for a reboot to be performed at the time. It's nice to be able to choose when a reboot is done instead of being told to do so immediately.

A rolling reboot of a cluster is actually quite easy: one node gets rebooted while the other stays the course. Of course this requires more than one system disk. When the first is completed then you continue on with the remaining nodes. Back in the day I worked in a place where we had a 18-node VMS cluster. What a project that was but at least we had 1 system disk per 9 nodes so during an upgrade all 18 nodes could run off of system disk 2 while system disk 1 was upgraded. Ah, those were the days!

[admin]

One may be at a point during the work day where an upgrade/update can be kicked off but it isn't convenient for a reboot to be performed at the time. It's nice to be able to choose when a reboot is done instead of being told to do so immediately.

Now I'm with you. There have been occasions when I have put off a reboot until it's been more convenient. I was under the impression that you were suggesting that incremental kernel changes could be implemented via patches that would "never" require a reboot. Which didn't make a lot of sense.

Alison

[rgbrock1]

One may be at a point during the work day where an upgrade/update can be kicked off but it isn't convenient for a reboot to be performed at the time. It's nice to be able to choose when a reboot is done instead of being told to do so immediately.

Now I'm with you. There have been occasions when I have put off a reboot until it's been more convenient. I was under the impression that you were suggesting that incremental kernel changes could be implemented via patches that would "never" require a reboot. Which didn't make a lot of sense.

Alison

Any kernel change, incremental or major, never REQUIRES a reboot until such time as it's convenient for the systems manager to do so OR when you wish to take advantage of those changes.

Unlike MS Windblows which requires an immediate reboot after ANY change, major or not.

[admin]

I thought we were discussing something meaningful not semantics. In my world upgrades are implemented solely for the purpose of making use of the changes brought about by the upgrade, not because you have nothing better to do at the time. As for changing code and leaving it languishing on a disk without implementation until some future time is a recipe for disaster.

Trouble shooting a system invariably requires backtracking on changes made, and the fewer carried out at any specific time the better. Changes to the kernel should be of such concern as to warrant implementation, and possible investigation without any possibility of the addition of further changes to the queue over time to muddy the waters.

System upgrades can often be cumulative, thus a change to to SELinux may be dependant upon previous kernel changes, and it is far too easy to assume that such changes have been made leading to system crashes when other functions get upgraded. So in this example SELinux gets an upgrade a few days later which doesn't require a reboot and gets implemented immediately, yet by virtue of holding off the kernel reboot you know have an unstable system which could do just about anything.

Alison (a one time Sys Admin)

[rgbrock1]

I thought we were discussing something meaningful not semantics. In my world upgrades are implemented solely for the purpose of making use of the changes brought about by the upgrade, not because you have nothing better to do at the time. As for changing code and leaving it languishing on a disk without implementation until some future time is a recipe for disaster.

Trouble shooting a system invariably requires backtracking on changes made, and the fewer carried out at any specific time the better. Changes to the kernel should be of such concern as to warrant implementation, and possible investigation without any possibility of the addition of further changes to the queue over time to muddy the waters.

System upgrades can often be cumulative, thus a change to to SELinux may be dependant upon previous kernel changes, and it is far too easy to assume that such changes have been made leading to system crashes when other functions get upgraded. So in this example SELinux gets an upgrade a few days later which doesn't require a reboot and gets implemented immediately, yet by virtue of holding off the kernel reboot you know have an unstable system which could do just about anything.

Alison (a one time Sys Admin)

I agree on all your points indeed. Especially this line: backtracking on changes made, and the fewer carried out at any specific time the better. Unfortunately all too often management gets in the way of this thinking.