You are not logged in.
Hello,
I am currently working with cloud-init and archlinux cloud images and I am having a few issues,
one of them is how to automate a reboot (if needed) when pacman updates the linux kernel or the initramfs.
the question initially raised here: How to know when a system needs to be updated due to process updates? now closed.
I have created a feature request here FS#67977 - linux: reboot-required but got a reply of wont fix (and to be honest I am okay with the answer) but I can not see a way to identify if a reboot (new vmlinuz/initramfs) is needed via the suggested answer of watching the pacman output.
I am willing to go the extra mile and provide a patch/request to cloud-init but I really dont see how to automate this process.
To give you an example of
# grep -Ei linux /var/log/pacman.log
[2020-09-14T16:06:27+0000] [ALPM] installed linux-api-headers (5.8-1)
[2020-09-14T16:06:30+0000] [ALPM] installed util-linux-libs (2.36-4)
[2020-09-14T16:06:31+0000] [ALPM] installed util-linux (2.36-4)
[2020-09-14T16:06:32+0000] [ALPM] installed archlinux-keyring (20200820-1)
[2020-09-14T16:06:36+0000] [PACMAN] Running 'pacman --noconfirm --sync linux'
[2020-09-14T16:06:39+0000] [ALPM] installed linux (5.8.8.arch1-1)
[2020-09-14T16:06:49+0000] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2020-09-14T16:06:49+0000] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
[2020-09-14T16:06:51+0000] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
[2020-09-14T16:06:53+0000] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
[2020-09-14T16:06:53+0000] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
[2020-09-14T16:07:07+0000] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
[2020-09-24T12:14:58+0300] [ALPM] upgraded linux (5.8.8.arch1-1 -> 5.8.10.arch1-1)
[2020-09-24T12:15:07+0300] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2020-09-24T12:15:07+0300] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img -S autodetect
[2020-09-24T12:15:14+0300] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
[2020-09-24T12:15:19+0300] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
[2020-09-24T12:15:19+0300] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
[2020-09-24T12:15:26+0300] [ALPM-SCRIPTLET] ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
but not related message in pacman.log
# grep -Ei reboot /var/log/pacman.log
#
So I am a bit lost here.
How can we automate this process and know when an archlinux VM needs reboot ?
So that we can make the appropriate changes to cloud-init to support this functionality when building cloud VMs ?
the easiest hack should be either in pacman or linux related packages and
touch /var/run/reboot-required
and remove this file upon boot.
Any advice should be welcomed,
thanks in advance.
Last edited by ebal (2020-09-24 09:32:31)
https://balaskas.gr
Linux System Engineer - Registered Linux User #420129
Offline
Offline
Short answer : if you need automatic reboots without admin interaction , don't use archlinux .
Longer answer :
Automated reboots on archlinux systems are a bad idea and often lead to unavailable servers / services .
The same is true for automated updates.
People that want to use archlinux in a server environment usually setup some test servers.
Those servers are updated / maintained, once the admin is satisfied the update / maintenance can be applied safely to the live servers they trigger it manually .
Maybe that workflow is suitable for your usecase ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Sounds like the whole premise here is automated updates, which WILL cause problems. You MUST read pacman's output or you could end up with a non-working system.
Offline
You only need to reboot if / when you want the new kernel to load or if you will need to load modules that you have not previously used. As very very few packages depend on a specific version of the kernel running, the former condition is not really ever required by packages - but it's just your own preference: is there something in kernel version N+1 that you think would really benefit your server? If not, there's no need to reboot into the new kernel for this purpose.
The other purpose is if you will need to load modules that have not already been loaded. If your server is up and running - and not undergoing significant configuration changes to use new tools / modules, this should also never really be the case. And even if it is the case, there are strategies to keep the old kernel modules around just for this purpose.
You can also ignore the kernel package (in pacman.conf) and even the above conditions would then never apply.
So I don't really know why a server would ever need a reboot except for those subjective cases of when you feel like the new kernel has something you really want: e.g., an important security patch would be a prime example.
My arch server is currently on ~6 months of uptime, and I don't forsee rebooting it anytime soon. I don't think I even had much of a reason to reboot last time I did. I was probably just bored.
So if your question is when does a system need to be rebooted because of software updates, the answer is never. You may have other reasons to reboot ... maybe, but not just because of software updates.
Last edited by Trilby (2020-09-24 13:29:45)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
grep -Ei ' linux | linux-lts ' /var/log/pacman.log
egrep -i ' linux | linux-lts ' /var/log/pacman.log
Offline
xerxes_ what is that supposed to indicate that wouldn't be much more clearly inferred from `pacman -Q linux` compared to `uname -r`? Or even simpler:
[ -d /usr/lib/modules/$(uname -r) ] || echo reboot needed
But again, this all assumes that a reboot actually is needed every time the kernel is upgraded. It isn't.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
I'd be more worried about systemd services and figure out what needs to be restarted or reloaded.
Offline
Sounds like you need something like RedHat's "needs-restarting" script: https://gist.github.com/fukawi2/dc806dd … 8a77a9d066
You'll likely need to make adjustments to suit Arch.
Last edited by fukawi2 (2020-09-25 04:47:16)
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Sounds like you need something like RedHat's "needs-restarting" script: https://gist.github.com/fukawi2/dc806dd … 8a77a9d066
You'll likely need to make adjustments to suit Arch.
Like this?
Offline
Hey, look at that... I was not aware we'd done our own version
Yes, like that.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
But again, this all assumes that a reboot actually is needed every time the kernel is upgraded. It isn't.
Already mentioned the why, so I'll cover ways to avoid the "missing module X" after kernel update (idk if servers need that, it's not that they change much on runtime ).
You can load what you'll need at boot with modules-load.d, read 'man modules-load.d'.
Another way is "backup the old kernel modules on update" from kernel-modules-hook, with known caveats...
People that want to use archlinux in a server environment usually setup some test servers.
Those servers are updated / maintained, once the admin is satisfied the update / maintenance can be applied safely to the live servers they trigger it manually.
Idk if that's available for mortals, maybe a server clone inside a chroot for admins tests as well?
Offline