Annual upgrade

Vitaliy · 2026-07-11 13:34:59

I'm planning to try Arch as a server OS. I'm currently using Debian.
My question is this: I've heard that rolling-release distributions require fairly frequent upgrades, but I haven't come across any specific information on how often.
If I upgrade Arch once every 6–12 months, will that cause any problems during the upgrade process?

cryptearth · 2026-07-11 13:36:54

counter-question: how often do you plan to perform system maintenance? if you answer is anything longer than "at least once a month" you shouldn't operate any server at all - no matter the os

Vitaliy · 2026-07-11 13:48:32

cryptearth wrote:

counter-question: how often do you plan to perform system maintenance? if you answer is anything longer than "at least once a month" you shouldn't operate any server at all - no matter the os

Thank you for your reply, but I wanted to clarify the technical feasibility, not the ethical one.

seth · 2026-07-11 14:00:50

If I upgrade […] will that cause any problems during the upgrade process?

Yes.

https://wiki.archlinux.org/title/System_maintenance

You can update arch annually, the main problem you might encounter is dated signature keys but there's a daemon that's supposed to keep those up-to-date and otherwise just pre-updating the keyring usually is sufficient. In doubt you'll have to perform incremental updates w/ the https://wiki.archlinux.org/title/Arch_Linux_Archive
The bigger issue w/ the approach is that arch doesn't provide integration-tested point releases so what you might find is that the update introduced a bug in software X and you'll have to run another update next week and maybe that then introduces the requirement to adjust the configuration of tool Y etc et pp.
Rolling releases are not suffer-through-the-upgrade-and-then-forget systems by nature, so whether this is a good idea is indeed a different question.

cryptearth · 2026-07-11 14:19:42

Vitaliy wrote:

I wanted to clarify the technical feasibility, not the ethical one.

my counter question IS technical, not ethical - because a server accessible from the open internet requires at least weekly if not daily maintenance
if you don'T want to or don't feel capable to keep up you just should not host a server yourself but rent a managed service
neither arch nor any other os is a "fire and forget once setup" thing you can run for a year without checking in every once in a while - which is what your question sounds like - and in this regard it doesn't matter if you go bi-anual from april to october and to april on every other ubuntu relaese or daily with arch - you have to ACTIVELY keep track of your system - otherwise your server WILL become a playground for whoever gets his hands on first

so, again: if your reply to "how often do you plan regular maintenance on your server" is similar to "how about never?" - renting and operating an internet-accessible server comes with responsibility - there're million zombies out there - we don't need another one
btw - depending on your hoster: the contracts usually imply active maintenance - not doing so (which IS tracked actively) is often reason for termination without refund
you should consider going for a managed option

Vitaliy · 2026-07-11 16:48:25

I understand. Thanks, everyone, for your replies.

Trilby · 2026-07-12 12:01:35

I support the intent behind cryptearth's first response in this thread - but their second comment is, I hope, deliberately exaggerated for effect. A (well-configured and properly secured) server most certainly does not need daily maintenance. That's just utter nonsense. Weekly is a pretty good guideline, but also not a strict requirement.

I maintain a business website server running arch linux and it gets updated much less frequently that is commonly advised. I last updated it about a month ago, but prior to that it had been about 6 months. On average it gets updates about every 3-6 months or so. I have had no problems whatsoever due to infrequent updates. But note that I've been using arch linux as my sole OS on many machines and a few servers over 15 years. I am well-versed at spotting "symptoms" and dealing with any problems that arise.

If you are new to arch linux, then running it on a server is probably a very bad idea just because you are not as familiar with arch itself. Further even if you are pretty familiar with arch as a desktop system, if it is your first use of it on a server, I'd strongly advise to not follow my example and instead stick to a schedule of regular updates. But monthly is certainly adequate.

Annual updates are unlikely to directly result in catastrophe, but inexperience paired with such infrequent updates is a recipe for disaster as there may be some manual intervention needed that could result in trouble if not handled properly.

It's also worth noting that if you do run into challenges and come here for help you may run into two flavors of hurdles. First, it is a bit disrespectful to rely on a community's support if you ignored that communities general guidelines for a long time. Second, many users here will respond to that (if you ask for help when annual updates lead to problems) by not offering help but instead only heaping on shame and ridicule. They're assholes, but they're plentiful.

Weekly to monthly updates are well within the appropriate range of maintenance that very few members here would question as suitable. Annual may work, but at that point you are pretty well outside the norm.

But also note that the more frequent updates are done, the faster and easier they are. So the technical constraints set a minimum, but really just every time you log into the server is a good time to upgrade. Daily updates can take a matter of seconds and generally result in no downtime (and with options like kexec and other live-reloads never require any downtime at all).

Last edited by Trilby (2026-07-12 12:07:42)

cryptearth · 2026-07-12 12:42:10

Trilby wrote:

but their second comment is, I hope, deliberately exaggerated for effect

kind of
my point is to make clear that server facing the public internet is not something you just setup once and then forget about it until something breaks (that's what i get from OPs posts) but that it requires active maintenance
if you do it daily or weekly - yes, this can be debated about - but as i already noted in my first reply: one should check the system at least once a month and perform required maintenance

mpan · 2026-07-13 01:29:29

I’ll branch off to a different perspective. Why are you worried about doing updates?

If you run a server for other people, you don’t need to answer this question. In this scenario you’re constrained to LTS versions and slowing down updates to appease server users. Arch is not the good option for this use case.

But in other situations I usually see two reasons being given. Both of which are inaccurate. For a specific example, I normally restart my systems bimestrial and it’s being that frequent by my own choice of sticking to the most recent minor kernel version.⁽¹⁾

Concerns about uptime and having to reboot. Most Linux-based systems, and Arch in particular, need a reboot only after a kernel update. All services, including init itself, can be reloaded at runtime without affecting the rest of the system.⁽²⁾ `systemctl daemon-reexec`, `systemctl restart`, knowing service’s built-in reload mechanisms (e.g. Nginx’s), and htop are your friends.

Arch has the “no partial upgrades” policy, but in practice kernel is treated with some leniency. This is because -Syu does not affect the running kernel anyway, and because kernels have very long compatibility periods as dependencies. While seeking help just be clear your kernel is older than the current, and be sure you checked it’s not the source of your trouble.

So you can easily get months long runtimes from Arch with all software below kernel being fully updated. Until there is a vulnerability or a serious bug to be patched. A situation that would force an update anyway. Even the oldest Debian repos backport patches and you have to pick them up and restart your services.

Dealing with breaking changes. With versioned distros you’re not avoiding these. You just need to face them all at once. It’s a matter of subjective preference which option do you prefer. But in my experience many people opting for the latter miss something. That “all at once” situation means that the entire update has to be postponed until each and every single incompatibility is resolved. With rolling updates you can postpone the update of a single component only. This puts you in the “partial upgrades are unsupported” territory. But mind entering this territory doesn’t say we’ll burn you on a stake for being there. This applies to receiving help in support channels.

To give you some example of how “don’t use rolling release” may be misleading, let’s look at a recent situation. Dovecot changed configuration format while transitioning from 2.3 to 2.4, together with making a few features no longer available. This is a royal pain. On Arch I just temporarily rolled back a single-package update, and Arch soon offered dovecot23 to make the transition less painful. You should see faces of people who updated Debian to Trixie expecting no major trouble in basic services. After negotiating all the minor incompatibilities learned that now they need to roll back the servers to Bookworm, because dovecot-core is at 2.4 only.

So don’t blindly assume that the other option is inherently less painful. We only choose the kind of pain.

____
⁽¹⁾ On a VPS this is 10–30 s downtime in 5.2 Ms. That’s five-nines, climbing towards six-nines availability.
⁽²⁾ Some exceptions exist, where a restart of one service may — in a non obvious way — affect another. These are rare, we learn them along the way.

Last edited by mpan (2026-07-13 01:31:11)

Trilby · 2026-07-13 11:34:00

mpan wrote:

So don’t blindly assume that the other option is inherently less painful. We only choose the kind of pain.

Indeed, while largely subjective, I would absolutely never run debian on a server. My experience with debian was relatively short and highly painful. Updates were less frequent, but when they happened it was basically just reinstalling the whole system from scratch. That's not something I want to go through on a regular basis. With arch, I can sail Theseus's Distro for a decade before returning to port for major overhauls.

Arch Linux

#1 2026-07-11 13:34:59

Annual upgrade

#2 2026-07-11 13:36:54

Re: Annual upgrade

#3 2026-07-11 13:48:32

Re: Annual upgrade

#4 2026-07-11 14:00:50

Re: Annual upgrade

#5 2026-07-11 14:19:42

Re: Annual upgrade

#6 2026-07-11 16:48:25

Re: Annual upgrade

#7 2026-07-12 12:01:35

Re: Annual upgrade

#8 2026-07-12 12:42:10

Re: Annual upgrade

#9 2026-07-13 01:29:29

Re: Annual upgrade

#10 2026-07-13 11:34:00

Re: Annual upgrade

Board footer