When the web app stops responding
I usually just restart it with systemd.
Edit: Initial D should be a nickname for the systemd init system.
I just go to the lil power strip and flick the the lil removed power button when I go to bed, then flick it back on when I wake up. It keeps the kids off the Wifis when we're supposed to be sleeping.
I was the "tech guy manager" for my regional office, for a major telecommunications company, for a non-trivial amount of time. Meritocracy in action, folks.
I like your style.
A lot of times I'll run apt-get update
/ apt-get upgrade
on my server and there will be no updates to install. I only reboot if there is a new kernel or something. Otherwise, I can just restart whichever services are directly impacted by the updates.
Debian Stable is a rock. Nothing ever changes. I do recommend subscribing to the debian-announce and debian-security-announce mailing lists though.
Nothing ever happens (in Debian).
when htop shows an exclamation point
(that's after around 100 days IIRC)
It's exactly around 100 days.
69 days.
Nice.
It depends on what you're hosting.
If this is a big site that experiences a lot of traffic, You should already have more than a single Web server anyway. If this is a website for a school or an organization, You really should have a load balancer and a couple web notes. In that situation upgrading and rebooting, draining traffic and bringing it back in, is fairly trivial.
If this is a home server, where you're the only real user, just reboot it.
Some distros like Ubuntu are better about fixing the security issues without requiring rebooting, but if it's a home web server the uptime is really not important.
Video. About 450 registered users. Maybe a couple dozen daily active; I haven't yet setup the monitoring tools to know exactly.
What's a web note?
Might have meant “nodes”?
If there's a serious security bug, like Heartbleed, you should totally update and reboot the service. That is basically the only "must" for staying atop things. The rest is mostly personal preference.
In my job I maintain publically exposed Linux servers, and many of them don't get rebooted for years. I think our record is about five years.
Yes, if you want your server to be theoretically the rootinest tootinest securest setup ever, you should update about every 6 hours, but even then you're just more vulnerable to repo attacks (which have happened a few times lately). Apt upgrade every month or three is probably good practice to keep on top of bugs.
So really, how frequently do you need to reboot? Eh. So long as it works, there are no critical kernel vulnerabilities, and updates are available, I really would argue you should never "have" to.
Servers are horses for courses, if you're being heavily targeted by hackers, obviously stay on top of updates, but if your server is pootling along without harassment and doesn't contain life-altering stuff if it got leaked, then don't worry too much. A standard, barely-changing, 'stable' build is usually a very secure one.
Thanks! Very informative.
are you able to move production traffic onto a different webserver?
Like a load balanced situation? Unfortunately, no. The app supports only a single server setup.
Not necessarily load balanced I suppose but say spinning up a new server and switching over using dns or something could work too. Then you keep both running while the first one drains. If thats not possible idk probably put up a notice on your site and do it at like 2am on a weekday
I could do that, but the server reboots faster than DNS records can update.
The high availability dilemma. Hardly ever need that hot spare. If 0 downtime isn't a requirement w/e
Sure but its less disruptive
Less dread that it won't come back online.
I only really restart if there's a kernel update because I'm too lazy to do all the setup for live patching. If there's an update for something like Nginx, I restart the service after updating it. I try to stay on top of updates, especially security ones for obvious reasons.
server: nginx/1.22.1
I also personally disable this, it's not really too important, but it's a little security by obscurity thing. Makes people scanning the internet for a specific (possibly vulnerable) version of Nginx a little bit harder.
Cool tip!
It really depends. I've seen servers that reboot every 24 hours as well as servers that are constantly up. I would say to reboot every kernel or systemd upgrade
I just do it whenever my package manager says to do it after the monthly sudo apt upgrade. Which is most months, but sometimes it doesn't, so I don't.
Ten minutes of downtime a month isn't a big deal.
On every kernel upgrade
bring back old forums that had a weekly scheduled reboot that was always the same but you would always forget about and panic for 10 seconds and be about to email the webmaster before remembering
(ok it was more about reindexing sql databases than updating the actual server kernel)
Maintenance is maintenance.
I restart mine (at least) when I upgrade to a new release, so when Debian 13 comes out I'll give them a reboot there.
whenever theres a kernel update
You should upgrade for security updates every six hours and reboot on every kernel upgrade
So you have cron handle your reboots?
I use unattended-upgrades on Debian to upgrade and reboot when necessary.
is that safe? ever had issues with updating production automatically?
I never had any issues with that
Some packages managers, including Debian APT, create a /var/run/reboot-required
file when an upgrade requires a reboot (like a kernel upgrade). If you have other reasons to reboot, it's up to you to find the best interval between reboots.
are you able to move production traffic onto a different webserver?
technology
On the road to fully automated luxury gay space communism.
Spreading Linux propaganda since 2020
- Ways to run Microsoft/Adobe and more on Linux
- The Ultimate FOSS Guide For Android
- Great libre software on Windows
- Hey you, the lib still using Chrome. Read this post!
Rules:
- 1. Obviously abide by the sitewide code of conduct. Bigotry will be met with an immediate ban
- 2. This community is about technology. Offtopic is permitted as long as it is kept in the comment sections
- 3. Although this is not /c/libre, FOSS related posting is tolerated, and even welcome in the case of effort posts
- 4. We believe technology should be liberating. As such, avoid promoting proprietary and/or bourgeois technology
- 5. Explanatory posts to correct the potential mistakes a comrade made in a post of their own are allowed, as long as they remain respectful
- 6. No crypto (Bitcoin, NFT, etc.) speculation, unless it is purely informative and not too cringe
- 7. Absolutely no tech bro shit. If you have a good opinion of Silicon Valley billionaires please manifest yourself so we can ban you.