gnu linux update question

Bryn M. Reeves bmr at redhat.com
Tue Jun 28 16:14:13 UTC 2011


On 06/28/2011 05:07 PM, Andrew Haley wrote:
> On 06/28/2011 04:59 PM, Petrus de Calguarium wrote:
>> It is common knowledge that one does not need to reboot for updates to take 
>> effect in GNU Linux.
>>
>> However, in actual practice, this is not so. I could cite many examples, but 
>> this should suffice:
>>
>> On Sunday evening, I installed a new updates-testing version of mesa and then I 
>> suspended the machine for the night. The following Monday morning (yesterday), 
>> I resumed the machine and suspended it again around noon. I again resumed the 
>> machine at about suppertime and _powered_ _it_ _down_ about 2 hours later. An 
>> hour or two after that, I powered it back up and the mesa testing update turned 
>> out to be bad and I was not able to log in. I did not know which program was at 
>> fault, because the bad program had been installed over 24 hours prior, but was 
>> only showing itself to be bad after a power off.
>>
>> Could someone explain how reboots are not needed in Linux for updates to 
>> _take_, given the evidence to the contrary.
> 
> If a process has a file open and that file is replaced with a new copy,
> the process is still using the file handle for the old file.  This is
> normal UNIX, nothing new.  How could it be otherwise?

Or to put it in simpler terms: when you update a component you need to re-start
the application(s) that use that component. When that is a component of the
whole desktop environment (like mesa) you will need to log out of your session
and log back in again.

For a couple of releases now the graphical updater tools have supported the
ability to warn the user when this is the case. If you were using these tools
then you should have received such a warning.

Note that suspending and resuming does not count here since you are simply
suspending the running (old) copy and then resuming it with open files and other
state intact.

Regards,
Bryn.



More information about the users mailing list