Keep Wi-Fi and Bluetooth RF State Across Boots with systemd-rfkill

You will finish with a safe way to inspect systemd-rfkill, confirm where the saved radio state lives, and decide whether boot restoration should be enabled. On this machine the installed package is systemd 255.4-1ubuntu8.17, providing the systemd 255 manpage. Allow about fifteen minutes. You need a shell and, for service status and journal details, an account permitted to read systemd's system view.

systemd-rfkill.service restores RF kill switch state early in boot and saves it when the state changes. RF kill is the kernel mechanism behind soft-blocking or hard-blocking wireless radios such as Wi-Fi and Bluetooth. The service is paired with systemd-rfkill.socket; it is normal for the service to be inactive between activations. That status alone is not a fault.

1. Confirm the installed unit and version

Start with read-only checks. They do not change radio state and do not need sudo:

$ dpkg-query -W -f='${Package} ${Version}\n' systemd
systemd 255.4-1ubuntu8.17
$ systemctl status --no-pager systemd-rfkill.service systemd-rfkill.socket
● systemd-rfkill.service - Load/Save RF Kill Switch Status
● systemd-rfkill.socket - Load/Save RF Kill Switch Status

The exact status lines depend on when the units last ran. Look for the unit names, a loaded unit, and the socket relationship. Do not interpret inactive (dead) for the service as proof that persistence is broken: this is a short-lived helper, while the socket provides the activation path.

Checkpoint: if systemd cannot find either unit, stop here. The installed package may have been built without RF kill support, or the unit files may not be present. Installing or replacing packages is outside this guide.

2. Inspect the unit definitions without changing them

Ask systemd to show the files it loaded. This is also read-only:

$ systemctl cat systemd-rfkill.service systemd-rfkill.socket

On a normal installation you should see the service invoking /usr/lib/systemd/systemd-rfkill and the socket associated with /dev/rfkill. The exact unit text can differ between distributions, so use the output from your host when investigating a problem. The manpage's executable path is the same path shown above.

Do not edit files under /usr/lib/systemd/system/. Package updates can replace them, and a local unit override can alter behaviour in ways that are hard to spot. First collect evidence with systemctl cat, systemctl status, and the journal.

3. Check the current RF state and saved files

Use the installed rfkill utility to display the kernel's current view:

$ rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

Your indexes and devices will differ. A soft block is a software state that can be changed by the operating system. A hard block is usually a physical switch, firmware setting, or platform hotkey and cannot be repaired by restarting systemd-rfkill. If a radio is hard-blocked, check the laptop switch or firmware controls before changing services.

The persistent files are under /var/lib/systemd/rfkill/:

$ sudo find /var/lib/systemd/rfkill -maxdepth 1 -type f -printf '%f\n'
0:phy0
1:hci0

Reading this directory may require elevated privileges. The filenames are host-specific and should not be guessed. An empty directory can be legitimate on a new installation or a host with no recorded state. Do not delete files to force a reset: that throws away the saved state without proving that the underlying device or boot sequence is healthy.

Checkpoint: record the output of both rfkill list and the directory listing before changing anything. This gives you a comparison point after a reboot.

4. Verify the activation and recent result

Read the service log for the current boot and the socket state:

$ journalctl -b -u systemd-rfkill.service --no-pager
$ systemctl is-active systemd-rfkill.socket
active

A successful invocation normally ends with an exit status of zero in the journal. The service may then return to inactive, because there is no long-running daemon to keep alive. If the journal shows a failure, collect the complete message before restarting anything:

$ systemctl status --full --no-pager systemd-rfkill.service
$ journalctl -b -u systemd-rfkill.service -n 50 --no-pager

These commands are ordinary diagnostics. Do not use systemctl restart as a generic repair step: the service restores state during its activation, so an unnecessary restart can change a radio's software block while you are troubleshooting. If you must test a restart during a maintenance window, save the output of rfkill list first and be prepared to restore the intended radio state with your normal desktop or hardware controls.

5. Understand the boot-restoration switch

The installed manpage documents one kernel command-line parameter, systemd.restore_state=. Its default is 1, which allows the saved RF settings to be restored during boot. With systemd.restore_state=0, systemd does not restore the settings at boot, but it still stores settings on shutdown.

Check what the current boot actually received before changing a bootloader configuration:

$ tr ' ' '\n' < /proc/cmdline | grep '^systemd\.restore_state='
systemd.restore_state=0

No output means the parameter was not supplied, so the documented default applies. If the output is systemd.restore_state=0, a saved block can remain on disk while the next boot deliberately ignores it. That is a common source of confusion: storage and restoration are separate decisions.

Changing a kernel command line is a boot configuration change and requires elevated privileges through your distribution's bootloader workflow. It can affect the next boot, and a malformed bootloader edit can make a machine harder to start. Make a backup using the bootloader's documented method, change only the parameter you intend to change, and verify the generated entry before rebooting. This guide does not prescribe a particular bootloader or configuration file.

Recovery is the inverse change: remove systemd.restore_state=0, or replace it with the default behaviour, regenerate the boot entry using your distribution's documented procedure, and reboot during a suitable maintenance window. After boot, rerun tr ' ' '\n' < /proc/cmdline, rfkill list, and the journal check above.

6. Separate systemd-rfkill problems from radio problems

If rfkill list shows a hard block, systemd is not the right place to fix it. If it shows a soft block that survives a deliberate user change, compare three points: the state before the change, the saved files after the change, and the state after a reboot. A missing or failed service invocation points to systemd, permissions, the kernel device, or package integration. A successful invocation followed by an unexpected state can instead indicate that another component, such as a desktop power manager or firmware, changed the radio later.

Keep the test small. Change one radio through the normal control already provided by your desktop or hardware, note the exact time, then inspect:

$ date --iso-8601=seconds
$ rfkill list
$ journalctl -b -u systemd-rfkill.service --since '5 minutes ago' --no-pager

Do not test by deleting /var/lib/systemd/rfkill/, disabling the socket, or masking the service. Those are persistent changes that remove the mechanism you are trying to measure. If you already made one of them, undo it with the matching systemctl unmask or package configuration procedure, then reload systemd configuration only when your distribution's instructions require it.