Skip to content
Presence & ProtocolAn independent guide to Jabber and XMPP

Servers

A server is a household: the weekly maintenance round

The daemon is the visible part. What keeps it running is a boring list, done on schedule, in the right order.

A wall calendar above a home office desk, a small server with status lights below it.

A small federated server is closer to a house than to a product. It does not need daily attention, it does need regular attention, and the failures that actually take it down are almost never dramatic: a certificate that expired on a Sunday, a log directory that quietly filled the disk, a package update postponed for eleven months. The maintenance literature of houses solves exactly this problem, and a household maintenance calendar states the principle plainly: care is a schedule, not a reaction, and the items on it are unglamorous, the roof, the drainage, the systems nobody admires until they fail.

A server’s round is shorter than a house’s year but shaped the same way. Some items are weekly, some monthly, some seasonal, and the value of the list is that it is written down before anything goes wrong. An operator who keeps the round finds that the server stops surprising them; an operator who does not is running on luck, and luck in infrastructure is just failure that has not happened yet.

What belongs on the weekly list?

The checks that are cheap and catch the common failures. Whether the host is answering on 5222 and 5269, both directions, because a client port can work while federation silently rots. Whether disk usage is climbing in the directories that grow, logs and message archives first. Whether the last update was applied, or is waiting. Whether the certificate’s expiry date is inside the next renewal window. None of these takes more than minutes, and the whole point of doing them on a fixed day is that none of them will ever announce itself politely.

The server implementations differ in where each of these facts lives. Prosody exposes a good deal of it through its documented admin interfaces, mod_admin_telnet and the module list; ejabberd keeps equivalent information behind its own commands; the comparison of the three daemons is the map of who puts what where. The checklist is the same either way: what changes is the command that reads it.

Why do the seasonal items matter more?

Because they are the ones that cannot be fixed in a hurry when they surface. Certificate renewal is the obvious one: an automated job that has been failing quietly for weeks announces itself as a federation outage, and the fix requires the DNS and the name to still be healthy, which is its own check. The domain renewal sits behind that, on a yearly cadence, and a lapsed registration is a different class of problem entirely, covered in the essay on the name and the DNS. Then there are the slow changes nobody schedules: the host image ageing, the dependency that stops being maintained, the backup that has never once been restored.

The house analogy earns its keep here. A homeowner who checks the gutters in autumn is not being diligent, they are paying a small cost to avoid a large one; a server operator who tests a restore in the quiet months is doing the same arithmetic. The seasonal item that gets skipped is always the one that mattered.

What does the round actually prevent?

Not failure, since components fail regardless, but surprise. A disk that fills is a fact; a disk that fills unnoticed for three months is a finding. The round converts the second into the first, and the difference shows in the incident log: operators who keep it describe their outages in past tense and short sentences, because the failure was found in the window where it was still small.

The written list also solves the handover problem that kills small services. A server run by one person is one decision away from abandonment, and a checklist written for a stranger is the difference between a service that can be handed on and one that dies with its operator’s attention. Community radio worked this out decades earlier, and the low-power stations’ habit of documented handover is the same maintenance truth told on the airwaves.

The list, kept short

Weekly: ports both ways, disk, updates, certificate window. Monthly: review the blocked and allowed lists, read a stretch of log rather than the dashboard, confirm the backup ran and could be opened. Seasonally: test a restore, renew what renews, re-read the DNS records against reality. The list is short on purpose, because a maintenance round that takes half a day is a maintenance round that stops happening.

What is being maintained is not really the server. It is the operator’s own habit of looking, and the habit is the part that cannot be reinstalled. A host can be rebuilt in an afternoon; a year of small, regular checks is the thing no image restores. That is the quiet conclusion the household writers reached first: the calendar is the tool, and the checklist is just the calendar written down.