A machine staying up for almost 3 years is irresponsible in this day and age. Yeah, I remember people having uptime competitions on Slashdot and the like some decades back, but you only need to look at the ssh logs of a 5 minutes old machine to realize this is a terrible idea in modern times.
Kernel bugs are rare. Most (almost every single) vulnerability can be patched without rebooting.
EPYC 7002 CPUs may hang after 1042 days of uptime
11–20 of 109 posts
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#12A machine staying up for almost 3 years is irresponsible in this day and age. Yeah, I remember people having uptime competitions on Slashdot and the like some decades back, but you only need to look at the ssh logs of a 5 minutes old machine to realize this is a terrible idea in modern times.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#13A machine staying up for almost 3 years is irresponsible in this day and age. Yeah, I remember people having uptime competitions on Slashdot and the like some decades back, but you only need to look at the ssh logs of a 5 minutes old machine to realize this is a terrible idea in modern times.
Air gapped machines and kernel live patching both exist.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#14A machine staying up for almost 3 years is irresponsible in this day and age. Yeah, I remember people having uptime competitions on Slashdot and the like some decades back, but you only need to look at the ssh logs of a 5 minutes old machine to realize this is a terrible idea in modern times.
1042 days ought to be enough for anybody
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#15Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#16A machine staying up for almost 3 years is irresponsible in this day and age. Yeah, I remember people having uptime competitions on Slashdot and the like some decades back, but you only need to look at the ssh logs of a 5 minutes old machine to realize this is a terrible idea in modern times.
Are you perhaps a Windows user? In the Linux world updates don't necessarily require reboots.
Yeah, you technically can replace on-disk files while services are running.
In practice this can cause trouble if an application wants to read an updated file at the wrong time, and library dependencies can require restarting a lot of stuff.
For ages people would install an update containing a security fix in glibc or libz or something, and keep on running the vulnerable version of the services that use them.
At that point you might as well reboot.
Modern Fedora has a very Windows-like mechanism where you reboot to update. You reboot, the system installs updates, then reboots again.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#17Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#18Back then intel were pressured into a recall, today we seem too willing to put up with being sold broken stuff.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#19Earlier quoted context omitted.
I dont understand opinons like this Just because it would be dangerous for your nodejs web_app.exe running on ubuntu behind apache fully exposed on the internet then there are billion other ways to use computers, like even air gapped systems. So, dont try to justify obvious flaw
I mean, hardware is cheap enough that any server of importance should be individually disposable. Yeah, you can do stuff to maximize uptime but if it needs to stay up that badly you have to consider the case of the hardware needing to be turned off at some point. > So, dont try to justify obvious flaw I'm not, it's a bug and should be fixed. But I think if anything is powered for 3 years straight it's a bit concernin…
Pretty much why Pawsey has an Annual High Voltage inspection shutdown [1]
> Otherwise you're liable to find things like [..]
TBH that's not really been an issue of note at any of the big iron farms I've been around since the 1980s .. generally there's a disciplined approach to maintaining 24/7/365 operation (that includes scheduled downtime for equipment checks) part of which is process documentation and justification and soft means of freezing | migrating processes+data etc.
Re: EPYC 7002 CPUs may hang after 1042 days of uptime
#20Earlier quoted context omitted.
Kernel bugs are rare. Most (almost every single) vulnerability can be patched without rebooting.
They're not that rare. Also, there are a lot of other updates that in practice should be followed up with a reboot. For example, any library consumed by systemd (such as openssl) usually requires pid1 to relaunch. For example, debian released an openssl update just yesterday. You can run "checkrestart -v" to try to figure out how to restart every affected app but you'll quickly run into systemd's init process running…
That does not require a reboot, `systemctl daemon-reexec` is enough.