On 2024-02-20, obs...@loopw.com <obs...@loopw.com> wrote: > > >> On Feb 20, 2024, at 2:31 AM, Thomas Schmidt <tschm...@htwg-konstanz.de> >> wrote: >> >> OP did indeed mean `sysupgrade`, > > which makes little sense _unless_ on -current, which will guarantee to break > this every sixth months when -current shifts about. > >> but fwiw, `syspatch && reboot` reboots >> your system if a patch as applied. I got it in all of my servers' >> cronjobs. > > Most of the patches don’t require a reboot.
Correct. Looking at the 7.4 patches, only 3 affect the kernel and definitely need a reboot to get applied: 002_msplit - requires reboot 008_vmm - requires reboot 009_pf - requires reboot Two where you don't really need to do anything other than apply the patch: 003_patch 004_ospfd (because, if you're affected by it, then things would be broken already) The rest don't actually need a reboot, but do need *some* things restarting if you're using them: 001_xserver 005_tmux 006_httpd 007_perl 010_xserver 011_ssh 012_xserver 013_unbound (Also: had there been fixes to libraries - libc, libssl, etc - they would be in this category too - you could figure out which long-running processes would need to be restarted and do that). However, considering the "*some* things need restarting" case, given what is available from syspatch, rebooting is the only reasonable way to automate making sure that anything needing a restart really is restarted. > This idea sounds horrible for uptime. Sorry. I’m not rebooting something > because a font was patched… There is a fairly high bar for a fix to get turned into a syspatch. Now, you might not be affected by every patched bug, and if you're updating manually then you can make that decision. But this thread is about automating, and the majority of syspatches do require processes to be restarted in order to take effect.
