another cc-connect instance is already running with config %

Error message

another cc-connect instance is already running with config %s

What it means

Same contention path as the PID variant: flock was held by another process, but readPIDFromLockFile could not recover a positive PID, so the error omits the PID and names only the config path. It still means another (or stale) instance holds the instance lock for this config.

Source

Thrown at cmd/cc-connect/instance_lock.go:57

	// Open/create the lock file
	f, err := os.OpenFile(lockPath, os.O_CREATE|os.O_RDWR, 0644)
	if err != nil {
		return nil, fmt.Errorf("cannot open lock file: %w", err)
	}

	// Try to acquire exclusive lock (non-blocking)
	err = syscall.Flock(int(f.Fd()), syscall.LOCK_EX|syscall.LOCK_NB)
	if err != nil {
		// Lock is held by another process
		f.Close()

		// Try to read PID from lock file for better error message
		pid := readPIDFromLockFile(lockPath)
		if pid > 0 {
			return nil, fmt.Errorf("another cc-connect instance is already running (PID %d) with config %s", pid, configPath)
		}
		return nil, fmt.Errorf("another cc-connect instance is already running with config %s", configPath)
	}

	// Write our PID to the lock file for diagnostics
	pid := os.Getpid()
	_ = f.Truncate(0)
	_, _ = f.Seek(0, 0)
	fmt.Fprintf(f, "%d\n", pid)

	return &InstanceLock{
		file:     f,
		path:     lockPath,
		acquired: true,
	}, nil
}

// Release releases the instance lock. It is safe to call multiple times.
func (l *InstanceLock) Release() {
	if l == nil || !l.acquired {

View on GitHub (pinned to 4000b2338a)

Solutions

Find the holder yourself: use lsof <configDir>/.<configBase>.lock or fuser to identify the locking process.
If no live process holds it, delete the lock file and restart cc-connect.
Check lock file readability/ownership (ls -l) and fix if owned by another user/root.

Example fix

// shell
// before
cc-connect  # another instance is already running with config ...
// after
lsof ~/.config/cc-connect/.config.toml.lock  # confirm no holder, then
rm ~/.config/cc-connect/.config.toml.lock && cc-connect

Defensive patterns

Strategy: try-catch

Try / catch

lock, err := AcquireInstanceLock(configPath)
if err != nil && strings.HasPrefix(err.Error(), "another cc-connect instance is already running") {
    // PID unknown — find holder externally, then decide stop vs remove lock
    exec.Command("sh", "-c", "lsof "+lockPath).Run()
    os.Exit(1)
}

Prevention

Treat this message as 'unknown holder' — investigate with lsof/fuser before deleting the lock.
Avoid manually editing/truncating lock files.
Ensure the process that creates the lock also writes its PID before any long work.

When it happens

Trigger: AcquireInstanceLock fails on syscall.Flock(LOCK_EX|LOCK_NB) and readPIDFromLockFile(lockPath) returns <= 0 — e.g. empty, corrupt, or unreadable lock file contents (PID write raced or file was truncated).

Common situations: The lock file was created by a process that died before writing its PID; a root-owned or unreadable lock file; manually truncated lock file.

Related errors

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/36e088a8760d4371. Report an issue: GitHub.