# Error: 11 the configuration database is locked

**URL:** <https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798>\
**Category:** CDB and CDB API\
**Created:** [October 25, 2016, 3:57am UTC](https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798 "2016-10-25T03:57:24Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![poornima11](https://avatars.discourse-cdn.com/v4/letter/p/dbc845/32.png) [@poornima11](https://dmap-community.ductus.global/u/poornima11)\
**Post date:** [October 25, 2016, 3:57am UTC](https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798/1 "2016-10-25T03:57:24Z")

</div>

Hello Team,

We are using netconf for our network related entries - Access points and clients to be more specific.  
For this we use a huge schema which includes all the configuration for a list of APs.

We have registered few action-points and subscriptions. Find the output of confd --status below.

_vsn: 6.0.2_  
_SMP support: no_  
_Using epoll: no_  
_available modules: backplane,netconf,cdb,cli,snmp,webui_  
_running modules: backplane,netconf,cdb,cli,webui_  
_status: started_  
_namespaces: urn:ietf:params:xml:ns:yang:iana-crypt-hash prefix:ianach exported to: all_  
\_ urn:ietf:params:xml:ns:yang:ietf-inet-types prefix:inet exported to: all\_  
\_ urn:ietf:params:xml:ns:yang:ietf-netconf-acm prefix:nacm exported to: all\_  
\_ urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring prefix:ncm exported to: all\_  
\_ urn:ietf:params:xml:ns:yang:ietf-netconf-notifications prefix:ncn exported to: all\_  
\_ urn:ietf:params:xml:ns:yang:ietf-yang-types prefix:yang exported to: all\_  
\_ urn:ietf:params:xml:ns:netmod:notification prefix:nm exported to: netconf\_  
\_ [http://tail-f.com/ns/aaa/1.1](http://tail-f.com/ns/aaa/1.1) prefix:aaa exported to: all\_  
\_ [http://tail-f.com/yang/acm](http://tail-f.com/yang/acm) prefix:tacm exported to: all\_  
\_ [http://tail-f.com/yang/common-monitoring](http://tail-f.com/yang/common-monitoring) prefix:tfcg exported to: all\_  
\_ [http://tail-f.com/yang/confd-monitoring](http://tail-f.com/yang/confd-monitoring) prefix:tfcm exported to: all\_  
\_ [http://tail-f.com/yang/netconf-monitoring](http://tail-f.com/yang/netconf-monitoring) prefix:tncm exported to: all\_  
\_ [http://tail-f.com/ns/webui](http://tail-f.com/ns/webui) prefix:webui exported to: all\_  
\_ [http://tembosystems.com/ns/datamodels/wireless](http://tembosystems.com/ns/datamodels/wireless) prefix:wireless exported to: all\_

_YANG data models: \_  
\_ module: iana-crypt-hash revision: 2014-04-04_  
\_ namespace: urn:ietf:params:xml:ns:yang:iana-crypt-hash\_  
\_ prefix: ianach\_  
\_ exported to: all\_  
\_ module: ietf-inet-types revision: 2013-07-15\_  
\_ namespace: urn:ietf:params:xml:ns:yang:ietf-inet-types\_  
\_ prefix: inet\_  
\_ exported to: all\_  
\_ module: ietf-netconf-acm revision: 2012-02-22\_  
\_ namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm\_  
\_ prefix: nacm\_  
\_ exported to: all\_  
\_ module: ietf-netconf-monitoring revision: 2010-10-04\_  
\_ namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring\_  
\_ prefix: ncm\_  
\_ exported to: all\_  
\_ module: ietf-netconf-notifications revision: 2012-02-06\_  
\_ namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-notifications\_  
\_ prefix: ncn\_  
\_ exported to: all\_  
\_ module: ietf-yang-types revision: 2013-07-15\_  
\_ namespace: urn:ietf:params:xml:ns:yang:ietf-yang-types\_  
\_ prefix: yang\_  
\_ exported to: all\_  
\_ module: netconf\_netmod\_  
\_ namespace: urn:ietf:params:xml:ns:netmod:notification\_  
\_ prefix: nm\_  
\_ exported to: netconf\_  
\_ module: tailf-aaa revision: 2015-06-16\_  
\_ namespace: [http://tail-f.com/ns/aaa/1.1\_](http://tail-f.com/ns/aaa/1.1_)  
\_ prefix: aaa\_  
\_ exported to: all\_  
\_ module: tailf-acm revision: 2013-03-07\_  
\_ namespace: [http://tail-f.com/yang/acm\_](http://tail-f.com/yang/acm_)  
\_ prefix: tacm\_  
\_ exported to: all\_  
\_ module: tailf-common-monitoring revision: 2013-06-14\_  
\_ namespace: [http://tail-f.com/yang/common-monitoring\_](http://tail-f.com/yang/common-monitoring_)  
\_ prefix: tfcg\_  
\_ exported to: all\_  
\_ module: tailf-confd-monitoring revision: 2013-06-14\_  
\_ namespace: [http://tail-f.com/yang/confd-monitoring\_](http://tail-f.com/yang/confd-monitoring_)  
\_ prefix: tfcm\_  
\_ exported to: all\_  
\_ module: tailf-netconf-monitoring revision: 2014-11-13\_  
\_ namespace: [http://tail-f.com/yang/netconf-monitoring\_](http://tail-f.com/yang/netconf-monitoring_)  
\_ prefix: tncm\_  
\_ exported to: all\_  
\_ module: tailf-webui revision: 2013-03-07\_  
\_ namespace: [http://tail-f.com/ns/webui\_](http://tail-f.com/ns/webui_)  
\_ prefix: webui\_  
\_ exported to: all\_  
\_ module: wireless\_config\_  
\_ namespace: [http://tembosystems.com/ns/datamodels/wireless\_](http://tembosystems.com/ns/datamodels/wireless_)  
\_ prefix: wireless\_  
\_ exported to: all\_

_user sessions:_  
\_ sessionId=11 2016-10-25 09:01:56 [admin@172.17.1.246](mailto:admin@172.17.1.246) netconf/ssh\_  
\_ no locks set\_  
\_ no transactions\_  
_callpoints:_  
\_ id=ap-radio-stats daemonId=0 daemonName=Netconf Proxy\_  
\_ id=ap\_status daemonId=0 daemonName=Netconf Proxy\_  
\_ id=discovered\_ap\_status daemonId=0 daemonName=Netconf Proxy\_  
\_ id=license\_counts \*\* not registered\_  
\_ id=license\_file\_oper\_data \*\* not registered\_  
\_ \*\*unknown id= daemonId=0 daemonName=Netconf Proxy\_

_validation points:_

_actionpoints:_  
\_ id=ap-config-point daemonId=10 daemonName=CDB action\_  
\_ id=ap-global-config-point daemonId=10 daemonName=CDB action\_  
\_ id=ap-image-file-download daemonId=10 daemonName=CDB action\_  
\_ id=ap-image-reset daemonId=10 daemonName=CDB action\_  
\_ id=approve-point daemonId=10 daemonName=CDB action\_  
\_ id=license daemonId=10 daemonName=CDB action\_  
\_ id=license-revoke-point \*\* not registered\_

_typepoints:_

_notification stream replay support:_  
\_ name=NETCONF \_  
\_ name=managed\_ap\_events \_

_SNMP inform delivery callbacks:_

_SNMP notification subscriptions:_

_authentication callback:_  
\_ not enabled\_

_authorization callbacks:_  
\_ not enabled\_

_error formatting callbacks:_

\_partial running locks: \_

\_partial candidate locks: \_

\_partial startup locks: \_

_cdb:_  
\_ current transaction id: 1477-310728-831843\_  
\_ running:\_  
\_ filename: /home/poornima/wlan/tools/confd/install/var/confd/cdb/A.cdb\_  
\_ disk size: 793.3 kB\_  
\_ ram size: 5.8065 MB\_  
\_ read locks: 0\_  
\_ write lock: unset\_  
\_ operational: disabled\_  
\_ no pending subscription notifications\_  
\_ registered cdb clients:\_  
\_ client name: Netconf Config Proxy 31190/6\_  
\_ type: subscriber\_  
\_ subscriptions:\_  
\_ db=running id=7 priority=0 path=/managed-ap/database\_  
\_ db=running id=6 priority=0 path=/system\_  
\_ client name: Netconf Config Proxy 31190/5\_  
\_ type: inactive\_

_tts alloc:_  
\_ 5765745 40:16733:246 64:61741:819 72:24:1 120:9:2 176:11:2\_

One of our action points writes configuration into the CDB using maapi calls. We would also be doing parallel reads to fetch the entry from the cdb. At some point we get this below error,

_DEBUG in use - the configuration database is locked_  
_0015165 | 2016-10-25, 09:17:11.347625 [confd\_nc][error] - Failed to add AP to CDB : 02:42:AC:11:02:04_  
_error: 11 the configuration database is locked_

Your assistance regarding this issue is very helpful.

Best regards

---

<div class="post-metadata">

**Author:** ![waitai](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/waitai/32/436_2.png) [@waitai](https://dmap-community.ductus.global/u/waitai)\
**Post date:** [October 26, 2016, 9:29pm UTC](https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798/2 "2016-10-26T21:29:39Z")

</div>

It is likely that you are running into a deadlock situation. Refer to the “Locks” section of the Advanced Topics Chapter in the ConfD User Guide for more information. The section on “Lock impact on user sessions” may provide a possible solution.

---

<div class="post-metadata">

**Author:** ![poornima11](https://avatars.discourse-cdn.com/v4/letter/p/dbc845/32.png) [@poornima11](https://dmap-community.ductus.global/u/poornima11)\
**Post date:** [November 2, 2016, 9:28am UTC](https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798/3 "2016-11-02T09:28:53Z")

</div>

Yes the user guide section was very helpful. But I need some further clarifications which are lacking in the section.

The operation we are doing is bulk commits using REST. So I presume it is the write lock which is being already taken during validate and one more commit fails with the error. Is this correct?

From the user guide, I understand that the transaction engine manages all transaction locks and there is no API exposing these transactional locks to the north-bound agent. How do I further debug this? Are there any specific logs I can enable?

Best regards,  
Poornima.M

---

<div class="post-metadata">

**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\
**Post date:** [November 2, 2016, 11:13am UTC](https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798/4 "2016-11-02T11:13:43Z")

</div>

> [@poornima11](#):
>
> From the user guide, I understand that the transaction engine manages all transaction locks and there is no API exposing these transactional locks to the north-bound agent.

There are global locks that can be taken, see the UG chapters that Wai pointed you to.  
In you case however, it seems like your application have started a CDB session through the CDB API. From the ConfD 6.2 UG Chapter 5.5. A session:

> It is important to consider that CDB is locked for writing during a read session using the C API. A session starts with cdb\_start\_session() and the lock is not released until the cdb\_end\_session() (or the cdb\_close()) call.

If you start a CDB session, and hence take a lock on CDB, then try to do a write transaction through MAAPI or any other northbound interface such as NETCONF, CLI, … the transaction will fail immediately unless you set the commit retry timeout to other than default. See /confdConfig/commitRetryTimeout in confd.conf

Using cdb\_start\_session2() instead of cdb\_start\_session() from your application you have some more options to the default lock that is used with cdb\_start\_session().

---

<div class="post-metadata">

**Author:** ![poornima11](https://avatars.discourse-cdn.com/v4/letter/p/dbc845/32.png) [@poornima11](https://dmap-community.ductus.global/u/poornima11)\
**Post date:** [November 3, 2016, 5:02am UTC](https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798/5 "2016-11-03T05:02:49Z")

</div>

Thanks a lot cohult.

Yes, I have set this timeout to 120s now and seems to have fixed the problem. But the confd.conf.full explains that this configuration is only for CLI. Since we are doing commits from rest should we use the commitRetry instead?

```
        Commit timeout in the CLI. This timeout controls for how
        long the commit operation will attempt to complete the
        operation when some other entity is locking the database,
        e.g. some other commit is in progress or some managed
        object is locking the database.

        There is a similiar configuration parameter,
        /confdConfig/commitRetry, which sets a timeout for all
        ConfD transactions, not just for CLI transactions.

```

Best regards

---

<div class="post-metadata">

**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\
**Post date:** [November 3, 2016, 8:59am UTC](https://dmap-community.ductus.global/t/error-11-the-configuration-database-is-locked/798/6 "2016-11-03T08:59:27Z")

</div>

Hi,

> [@poornima11](#):
>
> But the confd.conf.full explains that this configuration is only for CLI

That is a documentation bug in confd.conf.full. See the confd.conf man page instead.

The text in confd.conf.full describes `/confdConfig/cli/commitRetryTimeout` but is placed where `/confdConfig/commitRetryTimeout` is located.

I don’t know your use case, but setting the /confdConfig/commitRetryTimeout to 120s is in most cases a very long time. If you have a manager with a shorter timeout that might cause issues. So you probably want to take a look at if you can shorten your application read session time. I.e. the time your application spend between cdb\_start\_session() and cdb\_end\_session()/cdb\_close().