4 ms·
> Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched ver
by catdog 10y ago
> Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched versions.
It's possible determine what processes run outdated library code. There are tools which hook into the package manager which do this, like https://github.com/liske/needrestart https://github.com/liske/needrestart
- notalaser 10y agoLike I said, it's not entirely impossible (a while ago I was using checkrestart on my Debian machine with pretty good results), but the result is still somewhat clunky. There are a lot of things that aren't so easily checked: changes in interpreted code (needrestart can, fortunately, deal with Java, Perl, Python and Ruby, but I don't know how well, and there's no shortage of packages that rely on old-fashioned bash scripts or -- hey, Polkit! -- JavaScript), changes in configuration files and so on. This is a reasonable solution if you're running relatively non-critical processes on a single machine. If you really want to avoid downtime, a cluster with rolling updates seems like a solution with far fewer headaches. Non-critical covers a lot these days, fortunately :-).
- throwawayish 10y agoYes, clustering and virtualizing things is pretty much how this has been handled at a scale, be it modern web applications, (Open)VMS or mainframes. It's simpler and has other advantages to architect the application for this than to do the custom integration work required to make it work on a process/application level.
- notalaser 10y ago> (Open)VMS It'll eventually get reinvented :-).