You are not logged in.
Pages: 1
Anybody have a good heuristic for when to reboot after a system upgrade, and when that is unnecessary?
Reboot should probably occur:
if the kernel was updated;
if systemd was updated;
if libc or something fundamental like it was updated.
If something like libssl was updated, a reboot might be unnecessary, but an apache restart might be in order. And an sshd restart. And ... I don't even know! In which case, perhaps it needs to be a reboot!
When do you reboot after upgrades?
Offline
The only update that requires a reboot to put the new stuff to use is a kernel update. Why would you need to reboot for a libc update?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Many running daemons use libc as a shared library? Let's say the libc update fixed a securtity problem.
Offline
Then restart those daemons.
A reboot only allows one to remain ignorant of what said daemons might actually be doing. And by an extension of this logic, any update of anything can bring in new security patches/fixes, and therefore to ensure that all processes are restarted, a reboot is advisable after *any* update. Of course I don't think this is the case.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Basic rule is if you update any package and the executable / library in that package is in use. You need to restart that program / service.
If something like glibc or ssl (which is now used more or less by everything) is updated. Its best to reboot because that going to be faster way.
Offline
The only systematic way of doing this that I can think of is some version of this:
given the set of updated packages (S1)
determine the set of installed packages (S2) that have a (direct or indirect) dependency on one member of S1
determine the set of executables (E1) in S2
determine the list of executables (E2) currently running; this may be non-trivial because "bash foo.sh" runs both bash and foo.sh
intersect E1 and E2, to make E3
find the "correct" way of restarting each member of E3. This may be systemctl, but might not
I'm sure this algorithm is wrong is some way, which is sort of my point with this question. What do you guys do? Be as knowledgeable as possible, and hope for the best? :-) Or reboot all the time?
Offline
I envy you - I wish I had the time and brainpower to spare for worrying about reboot heuristics.
I reboot when the kernel upgrades - that's it. I've never experienced any adverse affects due to upgraded daemons that weren't restarted.
Offline
I have a fleet of machines for customers (each of which may have a different configuration), and I worry about missed security updates. I'd also like to avoid downtime aka reboot.
Last edited by jernst (2015-03-25 17:37:13)
Offline
why not both?
kexec-tools and the nice script allan broke into here could be useful.
Well, I suppose that this is somekind of signature, no?
Offline
What if you update something and run `pactree -r' on it and find
systemd was one of the dependencies? Do you restart systemd, and if so,
how?
What if you find linux was one of the dependencies? Do you still keep
running or reboot?
What if you find some applications are dependencies: should you restart those?
Last edited by kete (2015-03-25 22:59:13)
Offline
kete: these are all good questions. So what do you guys do for your machines?
Offline
Not really a Pacman Issue, moving to GNU/Linux...
Offline
What if you update something and run `pactree -r' on it and find
systemd was one of the dependencies? Do you restart systemd, and if so,
how?What if you find linux was one of the dependencies? Do you still keep
running or reboot?What if you find some applications are dependencies: should you restart those?
If a library is updated the programs that are linked against the library should be restarted in order to use the updated version. I don't think the kernel is dynamically linked, but systemd is. So if you update libc, then you'd have to restart systemd to have it load the new version of libc and therefore reboot. Right?
Another consideration is that if bash is updated, then you'll need to log out to restart the bash instance that you run when you log in.
I'd like to note that downtime itself is not an issue, what you want to avoid is having your daemons down. If you restart them, even without rebooting, they will be down for a short while. It'll be shorter than a reboot though.
I personnaly tend to reboot anytime a 'critical' library (e.g. libc) is updated on my servers, and after every update on my desktop.
Last edited by \hbar (2015-03-27 17:01:03)
Offline
If a library is updated the programs that are linked against the library should be restarted in order to use the updated version. I don't think the kernel is dynamically linked, but systemd is. So if you update libc, then you'd have to restart systemd to have it load the new version of libc and therefore reboot. Right?
systemctl daemon-reexec
Offline
Hi, I recently had this problem and found a script called checkrestart in debian-goodies. I managed to port it to pacman instead of dpkg, but it may be buggy, because I aren't exactly an expert in python.
Click me
Just put it in /usr/sbin and run it as root (guaranteed free of malware It needs root access to check all open file descriptors)
Offline
Hey @darthcookie, this could be useful, but I'm not quite understanding the assumptions here. From my (cursory) look at the source code, it looks like this script looks at open files, and based on that, determines whether a restart is needed. What if a running executable read in a file that has been updated, but doesn't keep the file descriptor open?
Offline
Hi, the script should indeed work like this, so it catches all changed executables and (dynamic linked) libraries. It is not able to detect cases of for example new config files, which are read on start up of the corresponding program, but these are created as .pacnew files when updated. Pacman does then inform the user about these files. So with the script and careful use of pacman, nearly all required restarts should be detectable.
Offline
Useful info:
$ cat /root/bin/stalelibs
#!/bin/bash
# Must be run as root, to see *all* potentially dead libs.
# From http://forums.gentoo.org/viewtopic-t-842297.html
lsof | grep 'DEL.*lib'
# Just the summary
# http://forums.gentoo.org/viewtopic-p-7364130.html#7364130
#lsof | grep 'DEL.*lib' | cut -d' ' -f1 | sort -u
Offline
Anybody have a good heuristic for when to reboot after a system upgrade, and when that is unnecessary?
Reboot should probably occur:
if the kernel was updated;
if systemd was updated;
if libc or something fundamental like it was updated.
I think you answered your own question.
Also, reloading/restarting apache, or whatever when some component it uses gets upgraded.
some daemons also need a systemctl daemon-reload after upgrades.
Offline
I reboot whenever I run into trouble. Generally this is from things like mount not working anymore after a kernel update, not being able to start games anymore after a graphics card driver update, etcetera.
Also I reboot whenever I run into a generic issue where I don't know the cause, because often just rebooting fixes whatever was wrong.
Offline
I generally reboot less then a week or bi weekly If a kernel update has been applyed, or I ended up with a large chunk of updates because I am on a trip or something.
Other then that, I haven't run into trouble with anything other then upstream issues like Xfce issues with font rendering with asian characters. Or a crash from flashplayer. Both of which are fixed. and flashplayer defenestrate a long time ago.
Last edited by cammyman50 (2015-08-30 17:58:17)
Offline
Pages: 1