user service '{}' is also declared in [bootstrap.linux.syste

Error message

user service '{}' is also declared in [bootstrap.linux.systemd.units]; declare it once

What it means

A user service name may not collide with a systemd unit declared in `[bootstrap.linux.systemd.units]`. `requests_from_config` cross-checks user service requests against declared system units and fails on duplicates, since managing the same name in two places would create conflicting definitions.

Source

Thrown at src/system/user_services.rs:281

/// Every user-scope service, validated, with names that collide with
/// `[bootstrap.linux.systemd.units]` or `[bootstrap.macos.launchd.agents]`
/// rejected (both would write the same unit or plist).
pub(crate) fn requests_from_config(config: &Config) -> Result<Vec<UserServiceRequest>> {
    let requests = compose_user_declarations(config)?
        .into_iter()
        .map(|(name, (declaration, origin))| {
            UserServiceRequest::from_toml(name, declaration, Some(origin))
        })
        .collect::<Result<Vec<_>>>()?;
    if requests.is_empty() {
        return Ok(requests);
    }
    let units = crate::system::systemd_from_config(config);
    let agents = crate::system::launchd_from_config(config);
    for request in &requests {
        if units.iter().any(|unit| unit.name == request.name) {
            bail!(
                "user service '{}' is also declared in [bootstrap.linux.systemd.units]; declare it once",
                request.name
            );
        }
        if agents.iter().any(|agent| agent.name == request.name) {
            bail!(
                "user service '{}' is also declared in [bootstrap.macos.launchd.agents]; declare it once",
                request.name
            );
        }
    }
    Ok(requests)
}

/// The mise executable a service definition may reference: the running
/// binary unless it lives in a temporary or remote-bootstrap staging
/// directory, else a `mise` on `PATH` outside those. Durability is judged
/// by where the binary really is, but the path kept is the one found: a

View on GitHub (pinned to afd2eddd3a)

Solutions

Delete one of the two declarations (keep the user service or the systemd unit, not both)
Rename one of them if both are genuinely intended to be different services

Example fix

// before
[[bootstrap.linux.systemd.units]]
name = "my-agent"
command = "my-agent"
[[bootstrap.linux.user_services]]
name = "my-agent"
command = "my-agent"

// after
[[bootstrap.linux.user_services]]
name = "my-agent"
command = "my-agent"

Defensive patterns

Strategy: validation

Validate before calling

function validateNoDupes(cfg) {
  const unitNames = new Set((cfg.bootstrap?.linux?.systemd?.units ?? []).map(u => u.name));
  for (const s of cfg.bootstrap?.linux?.user_services ?? []) {
    if (unitNames.has(s.name)) throw new Error(`user service '${s.name}' duplicates a systemd unit`);
  }
}

Prevention

Keep a single source of truth per service name
Search the whole config for a name before adding a new service entry

When it happens

Trigger: `requests_from_config` finds a user service request whose `name` equals a unit `name` in the systemd units config (src/system/user_services.rs:281).

Common situations: Migrating a service from system-level to user-level (or vice versa) and leaving both declarations; duplicating an entry while reorganizing bootstrap config.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/a54bf69b3d13cce2. Report an issue: GitHub.