SUMMARY:

This article provides information on how to remove a configuration lock which can affect committing a new configuration on the SRX.

SYMPTOMS:

In some cases, a commit attempt might fail with the following errors:

error: remote lock-configuration failed on node0

error: configuration database locked by …

CAUSE:

There can be different reasons for this issue to occur. Here is just one example.

When a user connects to the CLI, there is a process called mgd which will spawn a new child process for that user. This can be checked from the shell.

1. The user logs in:

root@SRX1% cli
{primary:node0}
root@SRX1>

2. A new mgdprocess is created:

root@SRX1% ps auxww | grep mgd
root 1271 0.0 2.6 43028 26876 ?? S 6:52AM 0:01.58 /usr/sbin/mgd -N
root 3159 0.0 0.3 43068 2768 ?? Ss 10:37AM 0:00.03 mgd: (mgd) (root)/dev/ttyp1 (mgd)  <<<<< this process is created

3. The user will now want to commit something and will go into configuration mode:

root@SRX1> configure exclusive
warning: uncommitted changes will be discarded on exit
Entering configuration mode

{primary:node0}[edit]
root@SRX1#

4. At this point, something goes wrong, and the user gets disconnected (for some unrelated reason). The user tries to log in again and finds that the node failed over. He still needs to commit his changes.

{primary:node1}
root@SRX2> configure
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
Entering configuration mode

{primary:node1}[edit]
root@SRX2# set interfaces ge-13/0/4 description test

{primary:node1}[edit]
root@SRX2# commit and-quit
node0:
error: configuration database locked by: root terminal u0 (pid 3159) on since 2016-12-15 10:20:02 UTC, idle 00:01:40 exclusive {secondary:node0}[edit]
Users currently editing the configuration:
root terminal u0 (pid 3159) on since 2016-12-15 10:20:02 UTC, idle 00:01:40
exclusive {secondary:node0}[edit]
node1:
error: remote lock-configuration failed on node0

This issue can also occur on a standalone SRX. When the user logs in, he will see a message similar to this one:

root@SRX> configure
Entering configuration mode
Users currently editing the configuration:
root terminal p0 (pid 2304) on since 2016-12-13 17:04:05 UTC, idle 1d 17:09
exclusive [edit]

In some cases, when he tries to commit a change, he will also get a message saying the system cannot lock the configuration.

SOLUTION:

Option 1:

The solution in this case is to clear the lock set by that mgd process. In the case of a standalone SRX, the administrator will issue the following command on the affected SRX:

root@SRX> clear system commit
No commit scheduled

root@SRX> configure
Entering configuration mode <<<< the lock has been removed

When a cluster is used, the recommended action is to use this command on both nodes:

{secondary:node0}
root@SRX1> clear system commit
No commit scheduled

{primary:node1}
root@SRX2> clear system commit
No commit scheduled

{primary:node1}[edit]
root@SRX2# commit and-quit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete.                <<<< commit is successful
Exiting configuration mode

Option 2:

root@s10-33> restart management
Management process started, pid 30895

WARNING: cli has been replaced by an updated version:
CLI release 18.1R3.3 built by builder on 2018-08-30 05:29:08 UTC
Restart cli using the new version ? [yes,no] (yes) yes

If this still does not work, you can kill it from shell using root access. (using this wayyou need to kill each mgd individually):

start shell user root
root@s10-33:RE:0% ps -auwx| grep mgd
root 4550 0.0 0.4 280500 7284 – I Sat07 0:00.08 /usr/sbin/mgd-api -N
root 30895 0.0 1.6 300196 32136 – S 17:31 0:01.24 /usr/sbin/mgd -N
root 30927 0.0 1.6 300196 32340 – Ss 17:31 0:00.05 mgd: (mgd) (root)/dev/pts/0 (mgd)
root 31039 0.0 0.1 8512 2192 0 S+ 17:32 0:00.01 grep mgd
root@s10-33:RE:0% kill 4550
root@s10-33:RE:0% kill 30895
root@s10-33:RE:0% kill 30927
root@s10-33:RE:0% exit

Option 3:

Try “mgd clr-chg” on both the nodes.

Normal Issues after doing this will get other issues. In that case you would need to restart the device and rollback to the last good configuration.

FW : mgd[66522]: ../../../../../src/ui/lib/access/dbase.c:2321: insist ‘dop->do_refcount != 0’ failed

error: session failure: unexpected termination