Difference between revisions of "Service Restart after Upgrades"

From Run Your Own
Jump to: navigation, search
(Notes)
(Find software that needs to be restarted)
 
(3 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
=== Find software that needs to be restarted ===
 
=== Find software that needs to be restarted ===
  
You can do that with <code>lsof</code> and looking for process that have opened files that are now gone. They are still in memory (otherwise said process would be quite unhappy), but they are not the same as they were on disk since the process first opened. That's a sign it has been most likely updated.
+
You can do that with <code>lsof</code> and looking for process that have opened files that are now gone (DEL). They are still in memory (otherwise said process would be quite unhappy), but they changed on disk since the process first opened them. That's a sign these files have been most likely updated, and the processes who need them should be restarted to benefit from their latest versions.
  
  sudo lsof | grep lib | grep DEL | awk '{print $1}' | sort | uniq
+
sudo lsof | grep lib | grep DEL                                    # verbosy
 +
  sudo lsof | grep lib | grep DEL | awk '{print $1}' | sort | uniq   # less verbosy
  
 
=== Restart service ===
 
=== Restart service ===
Line 15: Line 16:
 
=== Notes ===
 
=== Notes ===
 
* Most things can be restarted without creating havoc, in doubt, RTFM.
 
* Most things can be restarted without creating havoc, in doubt, RTFM.
* If needed <code>systemd</code> itself will have been most likely restarted by post-install package manager hooks/scripts. If you want to force restart the daemon, use <code>sudo systemctl daemon-reexec</code>. However whether or not the daemon was restarted does not mean that <code>systemd</code> related processes do not need to be restarted as well (for instance <code>journald<code>) but these are best restarted via <code>systemctl</code>.
+
* If needed <code>systemd</code> itself will have been most likely restarted by post-install package manager hooks/scripts. If you want to force restart the daemon, use <code>sudo systemctl daemon-reexec</code>. However whether or not the daemon was restarted does not mean that <code>systemd</code> related processes do not need to be restarted as well (for instance <code>journald</code>) but these are best restarted via <code>systemctl</code>. Just check the output of <code>lsof</code> to see if any of this applies to your situation.
  
  
 
[[Category: System]]
 
[[Category: System]]

Latest revision as of 12:57, 23 January 2019

After updating some software on a Linux machine, some services making use of this software will be restarted to make use of the new version. But most of the time, no. One way to refresh it all is to reboot, but unless there is a kernel update you should not need to do such thing.

Find software that needs to be restarted

You can do that with lsof and looking for process that have opened files that are now gone (DEL). They are still in memory (otherwise said process would be quite unhappy), but they changed on disk since the process first opened them. That's a sign these files have been most likely updated, and the processes who need them should be restarted to benefit from their latest versions.

sudo lsof | grep lib | grep DEL                                    # verbosy
sudo lsof | grep lib | grep DEL | awk '{print $1}' | sort | uniq   # less verbosy

Restart service

Well, you know... Once you have your list of processes who could do with some refreshing, their name should easily hint at the service you need to restart :)

sudo service whatever restart

Notes

  • Most things can be restarted without creating havoc, in doubt, RTFM.
  • If needed systemd itself will have been most likely restarted by post-install package manager hooks/scripts. If you want to force restart the daemon, use sudo systemctl daemon-reexec. However whether or not the daemon was restarted does not mean that systemd related processes do not need to be restarted as well (for instance journald) but these are best restarted via systemctl. Just check the output of lsof to see if any of this applies to your situation.