Hi there…
I’ve just noticed that updating a server won’t ask for a reboot even if I update core packages like kernel or glibc or openssl (for example)
ok, you can argue that if I see a “kernel” among the updated package I might guess that a reboot is needed… but what about other core packages?
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. 
first of all, I understand your point of view…
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 agree it would be a useful feature, expecially after the last update to CentOS 6.9!
There was a yum plugin (needs-restart?) that lists what services should be restarted, by looking at their opened files. It could be a starting point…
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.
What do you think?
I think @Imre_Bertalan is right. But what is about a hint:
Changes are done after reboot
So every admin knows that he has to reboot the server for example the next night.