jdx/mise · error

refusing unsafe change to bootstrap service '{}'; current st

Error message

refusing unsafe change to bootstrap service '{}'; current state remains unknown after systemctl daemon-reload

What it means

After performing `systemctl daemon-reload`, mise re-plans each bootstrap service before issuing follow-up commands. If the plan action is still `ResourceAction::Unknown` (unit still missing, inspection still unavailable, or the unit still cannot be enabled), mise aborts rather than apply changes to a service whose state remains unknown even after the reload.

Source

Thrown at src/system/services.rs:440

        let Some(parent) = path.parent() else {
            return false;
        };
        if !SYSTEM_UNIT_PATHS
            .iter()
            .any(|candidate| parent == *candidate)
        {
            return false;
        }
        path.file_name().is_some_and(|name| {
            name == self.unit.as_str()
                || instantiated_unit_template(&self.unit)
                    .is_some_and(|template| name == template.as_str())
        })
    }

    fn commands_after_reload(&self, notified: bool) -> Result<Vec<Vec<String>>> {
        if self.plan().action == ResourceAction::Unknown {
            bail!(
                "refusing unsafe change to bootstrap service '{}'; current state remains unknown after systemctl daemon-reload",
                self.name
            );
        }
        Ok(self
            .action(ServiceChange {
                notified,
                provides_unit: false,
            })?
            .map(|action| action.commands())
            .unwrap_or_default())
    }
}

const SYSTEM_UNIT_PATHS: &[&str] = &[
    "/etc/systemd/system.control",
    "/run/systemd/system.control",
    "/run/systemd/transient",

View on GitHub (pinned to 6f52dcdf99)

Solutions

1. Run `mise bootstrap plan` to see the persisted `current` state for the service
2. Verify the unit exists: `systemctl cat <unit>` and `ls /etc/systemd/system/<unit>`
3. Run `sudo systemctl daemon-reload` and `systemctl status <unit>` manually to see what systemd reports
4. If the unit should be managed by mise, declare it under `[[bootstrap.files]]` so the missing-unit case is resolved by the same run
5. Align `enabled`/`masked` desires with what the unit actually supports (static units cannot be enabled)

Example fix

# before: service references a unit nothing installs
[bootstrap.services.agent]
state = "running"

# after: supply the unit so it exists before follow-up commands
[[bootstrap.files]]
path = "/etc/systemd/system/agent.service"
source = "assets/agent.service"

[bootstrap.services.agent]
state = "running"

systemctl cat <unit> >/dev/null 2>&1 || echo "unit missing: will stay unknown after daemon-reload"

When it happens

Trigger: The apply pipeline reached `commands_after_reload` (daemon-reload already executed) but the unit is still absent on disk, systemctl is still unavailable, or the unit-file state is still non-enableable. Typical when a managed unit-file step failed or was skipped while the `[bootstrap.services]` entry references the unit.

Common situations: Unit file write failed or was reverted between steps; unit lives in a directory not scanned after reload; systemctl intermittently unavailable in the environment; a masked/static vendor unit that stays non-enableable.

Related errors

• refusing unsafe change to bootstrap service '{}'; inspect `m
• systemctl {} failed: {}
• conflicting bootstrap service declarations for {name}\n\n f
• bootstrap service '{name}' cannot be both masked and running
• bootstrap service '{name}' cannot be both masked and enabled

AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/bc79d09e685ba6e2. Report an issue: GitHub.