I can see why could it not ask for a reboot. Image yourself having a NethServer in production with a lot of users. If you update that already messes up things (just happened to me) but after it is done, everything will continue as it was. However, if you restart your server, then you might end up with a dead server. Remember, restart servers only if it is a MUST. (This is one thing I love in SUSE linux, Live patching. Hope we can soon implement the same here)
So not having a restart can come handy in terms of productivity. You can restart your server when it is the best suited for the users. I don’t want to imagine how dead I would be if I just restart it now. My users would tear down my door and hang me up with an UTP cable.
but think about a patch to glibc or openssl which closes a dangerous bug… I’d be suggested to reboot my server, shouldn’t I?
BTW, a unskilled user could update his server but keep it online with broken services and security flaws
in any case, in 15 years of centos derived distros I found myself with a broken server only 3 times, and the fault was always mine
(and I’d add that I never use the web UI to update my machines; I always use che CLI commands, 'cause I can read which packages will be updated, from which repo and so on)
I would agree it’d be helpful, especially as @Stefano_Zamboni points out with openssl, etc, ie Zentyal eventually implemented it, webmin does it, and of course Ubuntu throws a msg at login on the console… what I have not done is look to see if a msg shows in the console on our distro.
…to restart services registered in ConfigDB we could bind an action in “runlevel-adjust” event. The restart condition would be (more or less)
lsof | grep DEL
The runlevel-adjust is always triggered after a yum transaction.
For kernel updates we already have a TODO message that checks for NDPI support. It can be a good starting point. Modifying it and comparing the output of “uname” and the latest kernel is just a few lines of code.