Most of my Linux muscle memory is systemd-shaped — systemctl status, unit files, journalctl. Alpine runs OpenRC instead, and the mental model is different enough that a few early mistakes are worth writing down.
Runlevels are the whole model
OpenRC organizes services into runlevels — boot, default, shutdown, and any custom ones you define — and a service is "enabled" by being added to a runlevel, not by a standalone enable flag the way systemd units work. Adding a service to the wrong runlevel is the single easiest way to end up confused about why something didn't start on boot.
rc-update add <service> defaultadds a service to the default runlevel.rc-update showlists what's enabled where — this became my first troubleshooting step for anything that "should have started."rc-service <service> start/stop/restartcovers the day-to-day equivalent ofsystemctl.
Dependencies are declared, not inferred
Where systemd infers a lot of ordering from unit relationships, OpenRC service scripts declare their dependencies explicitly with need and use directives. A service that quietly assumes networking is already up will just fail intermittently on Alpine if that dependency isn't declared — it won't be inferred for you.
Logging is not journald
There's no journalctl equivalent baked in by default. Logging is whatever the service itself does — syslog, a log file, or nothing — so troubleshooting a service that fails silently on Alpine means finding out where that particular service actually writes its output, rather than reaching for one universal command.
OpenRC rewards knowing exactly what each service does. Systemd lets you get away with not knowing.
None of this is a complaint — Alpine's minimalism is exactly why it's a good fit for a small Ampere A1 box. It just means the first week runs on notes like these instead of habit.