I would like to run apt-get dist-upgrade, but I don't know how this will affect the currently logged in users. How can I find out:
1. will a restart be required
2. will the system be stable/functional until the restart if required (this page implies that there are times when the server will become non-functional until the restart)
3. will users have to log out before I run apt for updates to succeed
-
Could someone shed some light on the -1? – anregen Oct 20 '14 at 22:29
-
It's a flaw of serverfault where people can downvote without leaving a comment. It's really sad. Hope you have a thick skin. – captcha Oct 20 '14 at 23:11
-
1Seroiusly, you should be testing a dist-upgrade in your lab against your regression tests. At the same time you'll learn the answers to the rest of your questions. – user9517 Oct 21 '14 at 08:28
-
1@captcha *all* stack exchanges sites allow you to downvote with no comment. – tombull89 Oct 21 '14 at 08:30
-
1@anregen I believe that people are downvoting the question because it seems to indicate that you aren't experienced enough. Your question could marginally fail the test "Shows sufficient skill in the technology under question to be able to work on it for pay" (http://meta.serverfault.com/questions/4111/what-is-a-professional-capacity). I myself flirted with the idea of flagging your question as off-topic, although in the end I chose to reply to it. – Antonis Christofides Oct 21 '14 at 08:37
-
@tombull89 yeah, I realised that later too, thanks.. It's a flaw on all stack exchange sites. I really do not understand why they haven't fixed that yet. The most common reply I see from newcomers is the question 'why the downvote', which is very discouraging. You can only make a first impression once and I'm sure SE can do better than that. It's just a simple bit of code modification. – captcha Oct 21 '14 at 21:51
-
There's a basic set of knowledge assumed... and when people don't have that, downvotes tend to happen. Maybe that's wrong... – ewwhite Oct 22 '14 at 14:05
-
@AntonisChristofides Thanks for the feedback. I understand that this is commonly handled by assuming I'll need to restart, and scheduling time to do so. Most answers I've found can be summarized with "it depends, and you won't know for sure until after you hit enter". I was hoping for a way to find out in advance which updates require what post-upgrade actions. – anregen Oct 22 '14 at 16:47
-
@lain Are you saying you have a set of regression tests that perform tasks similar to your users, and you have duplicate test hardware in a test lab, so you're able to look at the results of a test run to predict user experience during a real upgrade? That sounds very impressive, but we have nothing close to that available. Nor do we have the budget to implement that. Unless I'm over complicating your statement. – anregen Oct 24 '14 at 21:12
2 Answers
In Linux, like I think in all Unixes, when a process has an open file, it can continue to access it even if you delete it. After deletion the file is unreachable by other processes (there is no directory entry for it), but processes that had opened it before deletion can continue to access it using the handle the kernel gave them when they had opened it. The kernel only goes on to really free up the disk space when the file is closed by all processes that use it.
So, when you run a small upgrade, such as apt-get upgrade
, this usually does not affect the system much. Suppose, for example, that apt
upgrades glibc
by deleting /lib/x86_64-linux-gnu/libc-2.13.so
and putting /lib/x86_64-linux-gnu/libc-2.14.so
in its place. This is an important update because practically everything uses the glibc
library. However, there will probably not be any glitches, because already running processes will continue to use the old, deleted file. New processes will use the new file. This is why, when there is a glibc
security update, we must restart all services after the update, but it's usually not necessary to restart the system.
There may be glitches, however, if a running process opens new files while it is running. A process might have the old version of file A already open, and it might attempt to open the new version of file B, and the new B could be incompatible with the old A. Or a program that had already been running before the update might try to open some libraries, and it might be incompatible with these. Or a program might try to access a library that used to be in some specific location, and now it might have been moved elsewhere. In my experience, such glitches happen mostly with big graphical applications. If I upgrade my system while working, at some point firefox stops responding or starts to behave strangely. Applications that run in terminals are less likely to be affected, but in major upgrades it's unlikely there won't be any glitch at all.
In addition, during the upgrades some services are turned down for some amount of time. And, also, things frequently go wrong in upgrades, resulting in crippled systems, which you then have to fix and it may take some time.
Bottom line: The extent to which your users will be affected depends on what they're doing and largely on chance. It is not unusual for them to not notice anything, but it would be unwise to bet your life on it.
As for the restart, apt-get dist-upgrade
will probably install a new kernel, but it will not uninstall the already running kernel. If you don't mind the fact you will still be running the old kernel, you can skip restarting. I believe that in theory you can fix almost any glitch without restarting the system (just by restarting services), but it's usually easier to restart the entire machine after big upgrades.
![](../../users/profiles/110653.webp)
- 2,556
- 2
- 22
- 35
-
Informative and nice answer, but I really don't get why anyone would run a dist-upgrade without rebooting the system. You're basically replacing everything in the base OS (including init and the kernel), why upgrade if you're not going to use it? Is it safe to wait until the next time you _desperately_ need to reboot and land in a situation where the server might not boot up due to a incorrect upgrade? – pauska Oct 21 '14 at 08:33
-
restarting every service does not fix kernel issues if there are some security problems with the kernel itself, so unless you are able to patch the running kernel (which is partly possible) you should restart for the kernel patches/the new kernel to actually be used. – Dennis Nolte Oct 21 '14 at 08:34
- will a restart be required
- will the system be stable/functional until the restart if required
- will users have to log out before I run apt for updates to succeed
- You should probably restart if this includes glibc and kernel updates.
- The system will likely function until you can restart, but if that's a concern, you should schedule a maintenance window and take care of your updates and downtime at the same time.
- You users should not need to log out, but again, coordinate your maintenance window with the users and the business.
This is a situation where you (as sysadmin?) have to manage user expectations. If you have a set of updates important enough to consider running them outside of a maintenance window, I think you can make the business case to get real downtime and do the work properly.
![](../../users/profiles/13325.webp)
- 194,921
- 91
- 434
- 799