another setup sync or pull is running; retry shortly

Error message

another setup sync or pull is running; retry shortly

What it means

The sync/pull flow serializes through a status lock file in the state directory. `lock_wait` polls `try_lock` until a deadline (`wait`); if the lock is still held when the deadline expires, it aborts with this error instead of corrupting shared status. No changes were made; the concurrent operation still owns the lock.

Source

Thrown at src/system/history/sync/run.rs:495

pub(crate) fn update_status(
    state_dir: &Path,
    wait: Duration,
    mutate: impl FnOnce(&mut SyncStatus),
) -> Result<()> {
    let _lock = lock_wait(state_dir, wait)?;
    let mut status = read_status(state_dir)?;
    mutate(&mut status);
    write_status(state_dir, &status)
}

pub(crate) fn lock_wait(state_dir: &Path, wait: Duration) -> Result<fslock::LockFile> {
    let deadline = Instant::now() + wait;
    loop {
        if let Some(lock) = crate::lock_file::LockFile::new(&lock_path(state_dir)).try_lock()? {
            return Ok(lock);
        }
        if Instant::now() >= deadline {
            bail!("another setup sync or pull is running; retry shortly");
        }
        std::thread::sleep(STATUS_LOCK_POLL);
    }
}

/// A desktop notification for conflicts that newly need a decision, when
/// `history.notify` is on. Notify once per whole-setup pause, not per path.
/// Never blocks; a failure is only logged.
fn notify_new_conflicts(status: &mut SyncStatus) {
    notify_conflicts_with(
        status,
        crate::config::Settings::get().history.notify,
        crate::system::history::notify::send,
    );
}

fn notify_conflicts_with(status: &mut SyncStatus, enabled: bool, send: impl FnOnce(&str, &str)) {
    let current: BTreeSet<String> = status

View on GitHub (pinned to afd2eddd3a)

Solutions

Retry the command shortly, once the other sync/pull finishes
Find and wait for/stop the concurrent process (`pgrep -af 'mise bootstrap dotfiles'`); if a process crashed and leaked the lock, remove the stale lock file in the mise state directory
Serialize automatic syncs (cron intervals) so they don't overlap interactive use

Example fix

// before
$ mise bootstrap dotfiles pull &
$ mise bootstrap dotfiles sync
error: another setup sync or pull is running; retry shortly

// after
$ mise bootstrap dotfiles pull
$ mise bootstrap dotfiles sync   # run sequentially

Defensive patterns

Strategy: retry

Validate before calling

pgrep -af 'mise bootstrap dotfiles' || mise bootstrap dotfiles sync

Try / catch

catch (e) { if (String(e).includes('another setup sync or pull is running')) { await sleep(2000); return retrySync(); } throw e; }

Prevention

Run sync/pull commands sequentially, not in parallel shells
Space out scheduled (cron) syncs and avoid overlapping with interactive use
Clean up stale locks after a crashed sync process

When it happens

Trigger: Running `mise bootstrap dotfiles sync` or `pull` while another sync/pull process already holds the status lock for longer than the wait deadline — e.g. two terminals, a scheduled background sync overlapping an interactive one, or a crashed process that leaked the lock.

Common situations: Cron/systemd-triggered periodic sync running at the same time as a manual pull; long-running sync on a slow network; stale lock left by a killed process.

Related errors

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