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

UpgradeDBs serializes the ledger data-format upgrade with other peer commands using a file lock (fileLock.Lock()) on a lockfile under the peer's root FS path. If the lock cannot be acquired — because another peer process (peer node start, upgrade, etc.) already holds it, or a previous run crashed leaving a stale lock — the underlying error is wrapped with this message and returned.

Source

Thrown at core/ledger/kvledger/upgrade_dbs.go:26

import (
	"github.com/hyperledger/fabric/common/ledger/blkstorage"
	"github.com/hyperledger/fabric/common/ledger/util/leveldbhelper"
	"github.com/hyperledger/fabric/core/ledger"
	"github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb"
	"github.com/pkg/errors"
)

// UpgradeDBs upgrades existing ledger databases to the latest formats.
// It checks the format of idStore and does not drop any databases
// if the format is already the latest version. Otherwise, it drops
// ledger databases and upgrades the idStore format.
func UpgradeDBs(config *ledger.Config) error {
	rootFSPath := config.RootFSPath
	fileLockPath := fileLockPath(rootFSPath)
	fileLock := leveldbhelper.NewFileLock(fileLockPath)
	if err := fileLock.Lock(); err != nil {
		return errors.Wrap(err, "as another peer node command is executing,"+
			" wait for that command to complete its execution or terminate it before retrying")
	}
	defer fileLock.Unlock()

	logger.Infof("Ledger data folder from config = [%s]", rootFSPath)

	dbPath := LedgerProviderPath(rootFSPath)
	db := leveldbhelper.CreateDB(&leveldbhelper.Conf{DBPath: dbPath})
	db.Open()
	defer db.Close()
	idStore := &idStore{db, dbPath}

	// Check upfront whether we should upgrade the data format before dropping databases.
	// If someone mistakenly executes the upgrade command in a peer that has some channels that
	// are bootstrapped from a snapshot, the peer will not be able to start as the data for those channels
	// cannot be recovered
	isEligible, err := idStore.checkUpgradeEligibility()
	if err != nil {

View on GitHub (pinned to 2736b63f8f)

Solutions

Find and stop the other peer process holding the lock (check ps for peer node processes) and retry the command once it exits.
If no peer process is running, remove the stale lock file in the peer's ledger data directory (fileLockPath under config.RootFSPath) and re-run.
Ensure only one peer command runs at a time; serialize operations in deployment scripts.
Move the ledger data directory off NFS to a local filesystem that supports flock properly.

Example fix

// before (concurrent, fails)
go peer node upgrade &
peer node upgrade // lock already held

// after (serialized)
wait $UPGRADE_PID // let first command finish and release the lock
peer node upgrade

Defensive patterns

Strategy: retry

Validate before calling

// check no other peer process is running and lock is free before invoking
if err := exec.Command("pgrep", "-x", "peer").Run(); err == nil {
    return fmt.Errorf("another peer process appears to be running")
}

Try / catch

for attempt := 0; attempt < 3; attempt++ {
    err := kvledger.UpgradeDBs(config)
    if err == nil || !strings.Contains(err.Error(), "another peer node command is executing") {
        return err
    }
    time.Sleep(30 * time.Second) // wait for holder to release lock
}

Prevention

Never run peer node commands concurrently against the same data directory
Check for stale lock files after unclean shutdowns before retrying
Serialize upgrade/repair steps in deployment automation
Avoid NFS for ledger data directories; use local filesystems with flock support

When it happens

Trigger: Calling kvledger.UpgradeDBs (or 'peer node upgrade') while another peer command holds the ledger file lock; a previous peer process crashed without releasing the lock; two upgrade/repair commands run concurrently; the lock file resides on a filesystem where locking fails (e.g. NFS without proper lock support).

Common situations: Running 'peer node upgrade' while the peer is still starting or running; stale lock file left after an unclean shutdown (kill -9, OOM); duplicated automation scripts starting two peer commands at once; shared data directories on NFS mounts.

Related errors

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