Obviously a reboot is required when loading a new kernel....
But in general, does yum leave some breadcrumb clue that some other process can check? For example, maybe there's something in the package files that yum sees and creates a "/rebootRequired" file which is always deleted upon booting?
If not, I think that'd be a cool idea.. the file could be /rebootRequired.txt
and contain a plain text list of packages that caused the condition. :-)
Thanks
Donald Russell wrote:
Obviously a reboot is required when loading a new kernel....
But in general, does yum leave some breadcrumb clue that some other process can check? For example, maybe there's something in the package files that yum sees and creates a "/rebootRequired" file which is always deleted upon booting?
If not, I think that'd be a cool idea.. the file could be /rebootRequired.txt
and contain a plain text list of packages that caused the condition. :-)
It is quite apparent that you have a Windows like mindset. I say this without any will to offend you; I just observe: 1) the reboot idea 2) the file name with lowercase and uppercase mixed 3) the file extension .txt
:-)
Now the serious answer. The kernel case is obvious; installing a kernel is useless without a reboot. But in other cases the new stuff will be used together with the old one. For example, replaced libs will be used by programs freshly started, and old libs will be used for programs already running. So, the reboot is not strictly required. maybe you may want to restart some services or applications. And it always depends on the specific use of the apps. Say you install a new "tail" command with a security related fix. Would you reboot? Maybe not. But.... if you have a running tail -f on some log files where things under external control may be printed? Then maybe yes. Or.... you just restart the logging script, right?
There are some cases (glibc vulnerability for example) where a reboot could be a good idea. But, guess what, if you upgrade glibc, the sshd process will be restarted (!) as that is considered an extremely sensitive daemon. I may want to restart network facing stuff like httpd, firefox and something else, but I do not worry too much about the clock applet currently running the unfixed glibc.
(The iwl Intel driver forced me to reboot my laptop after more than 150 days and I had really bad words in my mind for Intel and their buggy code; my work session was incredibly complex and useful to me... I hate reboots).
On Thu, Jul 2, 2009 at 13:49, Roberto Ragusa mail@robertoragusa.it wrote:
Donald Russell wrote:
Obviously a reboot is required when loading a new kernel....
But in general, does yum leave some breadcrumb clue that some other process can check? For example, maybe there's something in the package files that yum sees and creates a "/rebootRequired" file which is always deleted upon booting?
If not, I think that'd be a cool idea.. the file could be /rebootRequired.txt
and contain a plain text list of packages that caused the condition. :-)
It is quite apparent that you have a Windows like mindset. I say this without any will to offend you; I just observe:
- the reboot idea
- the file name with lowercase and uppercase mixed
- the file extension .txt
:-)
Now the serious answer. The kernel case is obvious; installing a kernel is useless without a reboot. But in other cases the new stuff will be used together with the old one. For example, replaced libs will be used by programs freshly started, and old libs will be used for programs already running. So, the reboot is not strictly required. maybe you may want to restart some services or applications. And it always depends on the specific use of the apps. Say you install a new "tail" command with a security related fix. Would you reboot? Maybe not. But.... if you have a running tail -f on some log files where things under external control may be printed? Then maybe yes. Or.... you just restart the logging script, right?
There are some cases (glibc vulnerability for example) where a reboot could be a good idea. But, guess what, if you upgrade glibc, the sshd process will be restarted (!) as that is considered an extremely sensitive daemon. I may want to restart network facing stuff like httpd, firefox and something else, but I do not worry too much about the clock applet currently running the unfixed glibc.
(The iwl Intel driver forced me to reboot my laptop after more than 150 days and I had really bad words in my mind for Intel and their buggy code; my work session was incredibly complex and useful to me... I hate reboots).
Thanks Roberto...
I'll try not to take offense at your observations of me based on my original query. ;-)
Generally speaking I do not reboot my Linux machines unless I've installed a new kernel. There have been times though when "things seemed odd" after a particularly large number of updates were applied... rather than spend untold amounts of time trying to solve them, I did a quick reboot... perhaps that was overkill, but it definitely caused all processes to restart.
Perhaps if I knew more of the internal details of what's what, I'd have known that all was needed was to restart daemon "x"...
But, I'm not a member of that elite group (who know everything and are much holier than "Windows mindset" people), so I do what works quickly and leaves little unknown afterward.
I appreciate your explanations above, thanks for that.
Cheers
Donald Russell wrote:
Obviously a reboot is required when loading a new kernel....
But in general, does yum leave some breadcrumb clue that some other process can check? For example, maybe there's something in the package files that yum sees and creates a "/rebootRequired" file which is always deleted upon booting?
If not, I think that'd be a cool idea.. the file could be /rebootRequired.txt
and contain a plain text list of packages that caused the condition. :-)
Thanks
I cheat - I have this little icon that pops up on my top tool bar that tells me when I have updates. It changes when I tell it to install updates, showing me the progress. When it is all don, it vanishes, unless I need to do something like log out, or reboot...
Mike
Donald Russell wrote:
There have been times though when "things seemed odd" after a particularly large number of updates were applied... rather than spend untold amounts of time trying to solve them, I did a quick reboot... perhaps that was overkill, but it definitely caused all processes to restart.
Well, in general besides for a kernel update not much necessitates a reboot. In general, if 'things seem odd', you might want to consider one or more of the following things before a reboot: a. Log out and log back in (if updates seem to contain a lot of desktop related stuff) b. Log out, kill and restart the X/display manager (Ctrl+Alt+Backspace) (if there is an xorg package in the update) c. Login through a virtual console (Ctrl+Atl+F[12345]) as root i. Go to init level 3 and return back to init level 5 ii. Go to init level 1 and return back to init level 5 (if there are a whole bunch of updates which you don't want to check/guess about)
That was just a kind of thumb-rule -- the steps may/may not be necessary, but they are better than a reboot.
Perhaps if I knew more of the internal details of what's what, I'd have known that all was needed was to restart daemon "x"...
But, I'm not a member of that elite group (who know everything and are much holier than "Windows mindset" people), so I do what works quickly and leaves little unknown afterward.
Like Roberto, I do not intend to offend, but it is generally a good idea to:
a. Know what the services that are currently running on your system do. I don't mean you should read up all the man pages for all the daemons in depth, just learn why a service is/isn't required to run and then turn off the unnecessary ones.
b. Know what are the effect of the updates that you apply. Again, i don't mean read the changelog for all the updates being applied ...just check to see which area of the system they affect.
It takes just a little time but you'll learn a lot about your system that way. I know I do.
hth, cheers, - steve
There have been times though when "things seemed odd"
Yea, in particular all the maze of interlocking gnome daemons and random gconf changes that may or may not be made by some update can often leave previously running components not talking clearly to newly loaded updated components. You may or may not be able to find enough ways to restart things to clear up the problems, rebooting is usually much easier than doing the 6 months of research to determine which daemon has an impedance mis-match :-).
Donald Russell wrote: There have been times though when "things seemed odd" after a particularly large number of updates were applied... rather than spend untold amounts of time trying to solve them, I did a quick reboot... perhaps that was overkill, but it definitely caused all processes to restart.
One quick way to see which processes are using older (deleted) files is a script I found on fedora-devel-list called "wasted-ram-updates.py":
http://markmail.org/message/dodinyrhwgey35mh
After updates, I always run this to see which processes need to be restarted. Note that a few entries in this list are "normal" e.g. a program opens a file for temporary storage, and then deletes it (but keeps the handle), but most will indicate a process that needs to be restarted to reload files from a new package.
Depending on the process, a service or application restart may be enough, or if X/Gnome/KDE files have been updated, a restart of the X server may be required. I think the only times I have ever required a total reboot are kernel updates.
Cheers, Raman
Donald Russell wrote:
Obviously a reboot is required when loading a new kernel....
Well, actually... http://www.ksplice.com/ They make special patches for kernel which can be applied to a running kernel. Not sure this one is open source, but there probably will be one soon :)
On Fri, 2009-07-03 at 02:44 -0400, Raman Gupta wrote:
Depending on the process, a service or application restart may be enough, or if X/Gnome/KDE files have been updated, a restart of the X server may be required. I think the only times I have ever required a total reboot are kernel updates.
I reboot on updates of libc, which is used by virtually every process. Also, as long as you're not running a server, it's often easier and faster to reboot if you aren't sure.
poc
On Thu, Jul 2, 2009 at 23:44, Raman Gupta rocketraman@fastmail.fm wrote:
One quick way to see which processes are using older (deleted) files is a script I found on fedora-devel-list called "wasted-ram-updates.py":
Thanks... That's very cool, and exactly the type of thing I was looking for....
I'm going to add that to my "update process" :-)
Cheers, Don
Konstantin Svist wrote:
Well, actually... http://www.ksplice.com/ They make special patches for kernel which can be applied to a running kernel. Not sure this one is open source, but there probably will be one soon :)
Well, it is and it's even packaged in Fedora, but they don't produce patches for Fedora kernels and it's nontrivial to create them (they have some automated tools which work on the source code patches, but you need to feed them the patches by hand as the Fedora updates don't contain them in an appropriate format and those tools don't handle data structure changes, which makes them unusable for Fedora's kernel updates; I've been told that they now have infrastructure to handle data structure changes, but it requires writing patch scripts by hand and they aren't providing that service for Fedora).
Kevin Kofler