as another peer node command is executing, wait for that com

Error message

as another peer node command is executing, wait for that command to complete its execution or terminate it before retrying

What it means

NewProvider wraps the leveldbhelper file lock error with this message. The provider takes an exclusive file lock (fileLockPath under RootFSPath) to guarantee only one peer process accesses the ledger data. If flock fails because another process holds it, this error is returned.

Source

Thrown at core/ledger/kvledger/kv_ledger_provider.go:95

	}

	defer func() {
		if e != nil {
			p.Close()
			if errFormatMismatch, ok := e.(*dataformat.ErrFormatMismatch); ok {
				if errFormatMismatch.Format == dataformat.PreviousFormat && errFormatMismatch.ExpectedFormat == dataformat.CurrentFormat {
					logger.Errorf("Please execute the 'peer node upgrade-dbs' command to upgrade the database format: %s", errFormatMismatch)
				} else {
					logger.Errorf("Please check the Fabric version matches the ledger data format: %s", errFormatMismatch)
				}
			}
		}
	}()

	fileLockPath := fileLockPath(initializer.Config.RootFSPath)
	fileLock := leveldbhelper.NewFileLock(fileLockPath)
	if err := fileLock.Lock(); err != nil {
		return nil, errors.Wrap(err, "as another peer node command is executing,"+
			" wait for that command to complete its execution or terminate it before retrying")
	}

	p.fileLock = fileLock

	if err := p.initLedgerIDInventory(); err != nil {
		return nil, err
	}
	if err := p.initBlockStoreProvider(); err != nil {
		return nil, err
	}
	if err := p.initPvtDataStoreProvider(); err != nil {
		return nil, err
	}
	if err := p.initHistoryDBProvider(); err != nil {
		return nil, err
	}
	if err := p.initConfigHistoryManager(); err != nil {

View on GitHub (pinned to 2736b63f8f)

Solutions

Find and stop the other process holding the lock (pgrep peer; kill it) and retry
In Docker/K8s ensure the old peer container fully exits before the new one starts
Never run peer node commands concurrently with a running peer on the same RootFSPath
If no process exists but the lock persists (unusual), verify filesystem supports flock and check for stale NFS mounts

Example fix

// before: two peers on same data dir -> error
// after:
# pgrep -a peer
# kill <pid>; wait for exit
# peer node start

Defensive patterns

Strategy: retry

Validate before calling

// Before peer start, ensure no other peer holds the lock:
if err := exec.Command("flock", "-n", lockPath, "-c", "true").Run(); err != nil {
    return errors.New("another peer process is running on this data directory")
}

Try / catch

err := startPeer()
if err != nil && strings.Contains(err.Error(), "another peer node command is executing") {
    time.Sleep(2 * time.Second) // wait for prior process/container to exit
    err = startPeer()            // bounded retries
}

Prevention

Use process supervision (systemd/K8s) ensuring old peer fully exits before restart
Never run peer node admin commands while the peer is running on the same RootFSPath
One ledger data directory per peer process, always

When it happens

Trigger: Starting a peer (or any NewProvider-based command like peer node start/reset/rollback/upgrade) while another peer process or stale command still holds the file lock at RootFSPath/fileLock.

Common situations: Double-starting the peer, a previous peer process not fully terminated (hung or orphaned), running 'peer node reset' while the peer is running, or a container restart race where the old process lingers.

Related errors

AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/4633efd583ee207b. Report an issue: GitHub.