How do you know when a reboot is required after yum update?

[Don Russell]

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

[Kevin Kofler]

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

[Don Russell]

On Thu, Jul 2, 2009 at 23:44, Raman Gupta <rocketraman(a)fastmail.fm&gt; 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":
>
>  http://markmail.org/message/dodinyrhwgey35mh
>
>  
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

[Patrick O'Callaghan]

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

[Konstantin Svist]

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 :)

[Raman Gupta]

>  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

[Tom Horsley]

>  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 :-).

[steve]

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

[Mikkel]

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
-- 
Yes, I'm a dirty old man ...
and I'll be one until I'm a DEAD old man!

[Don Russell]

On Thu, Jul 2, 2009 at 13:49, Roberto Ragusa <mail(a)robertoragusa.it&gt; 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:
>  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).
>  

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

[Roberto Ragusa]

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).

-- 
   Roberto Ragusa    mail at robertoragusa.it