Re: The DHCP database could not be locked. Please retry the comm

halima.naboulsi · ‎05-11-2011

Hello,

I have this error message on my C6506:

The DHCP database could not be locked. Please retry the command later

I had this error even I'd execute any command line (sh run, sh ver ...)

Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport

Compiled Sat 23-Oct-10 01:30 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

cf65-tunis2 uptime is 16 hours, 15 minutes

Uptime for this control processor is 16 hours, 15 minutes

Time since cf65-tunis2 switched to active is 16 hours, 14 minutes

System returned to ROM by reload at 22:34:56 met_dst Tue May 10 2011 (SP by reload)

System restarted at 22:38:16 met_dst Tue May 10 2011

System image file is "sup-bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXI5.bin"

Last reload reason: Reload Command

Could you help me please?

Thanks and Regards,

Halima

Calin C. · ‎05-11-2011

CSCsw16698 Bug Details

DHCP database could not be locked DHCPD process could not lock semaphore

Symptoms: New DHCP clients are not able to get IP address from DHCP server via
DHCP relay on the router. Existing clients are unable to renew their IP addresses

Other Symptoms:

1.1 When we're trying to display DHCP bindings with "show ip dhcp binding"
command the following message is observed:

% The DHCP database could not be locked. Please retry the command later.

1.2 Command "ip dhcp database" dissapeared from the running configuration.

1.3 Output of "show run" is delayed.

1.4 Output of "debug ip dhcp events" show the following when a new DHCP packet
is received:

DHCPD: dhcpd_receive_packet: unable to lock semaphore to check for pre-existing
bindings could not lock se.
DHCPD: dhcpd_timer_process could not lock semaphore.
DHCPD: dhcp_server_receive could not lock semaphore.

2.1. This bug may also cause DHCP Snooping failure. In this case, the output of
the show ip dhcp snooping database command constantly shows
these lines:

Agent Running : Yes
Delay Timer Expiry : 0 (00:00:00)
Abort Timer Expiry : Not Running

Conditions: Occurs when DHCP and/or DHCP Snooping database agent is configured
to store bindings on a TFTP server, and then the database files are not present
or are read-only for some time on TFTP server while the router tries to write
to them.

Workaround: Before the issue occurs, there are three known alternatives to
avoid this problem:

1. Either configure 'length 0' for line console 0;

2. Or - log in via console at least once since router startup;

3. Or - use Cisco IOS Release 12.2(33)SRD but do not enable 'debug tftp packet'.

To fix the issue after it has occured, connect to the router via console, press
space bar to get rid of '--More--' prompt, then press enter to log in

Supposed to be solved in SXI5, but try one of the Workarounds and let us know if it's working.

Cheers,

Calin

halima.naboulsi · ‎05-11-2011

Hello,

Thanks you for your reply.

I've seen this bug explanation, but this big is not for C6506 is for C7200 series.

I'll try one of these workarounds and give you a feedback.

Thanks and Regards,

Halima

Calin C. · ‎05-11-2011

I've found this bug in cross-platform IOS release notes. I think it may apply to multiple platforms.

Gurpreet Kochar · ‎05-13-2011

If DHCP server ping is active, more specific, if the default setting for using ping to verify addresses is active, the DHCP server replies to requests only every other second. If the number of DHCP requests is larger than 50 in a short period of time, requests will get dropped, since the socket only queues up to 50 packets. Also, queueing increases reply time beyond the retry timeout, the clients will start to retry, which subsequently will increase the number of packets waiting in the queue, which in turn makes the behavior worse. Don't know what the solution would be, but the current solution is definitely not well scalable. Maybe ping can be handled asynchronously or prior to making an address available for use. One option might be to run a separate dhcp ping task to keep the DHCP server itself from blocking.

Please configure the following command if the issue persist and it should for sure take care of it

“ip dhcp ping packet 0

Ivan Prikhodko · ‎05-07-2016

Thank you, it really solve the issue on my Cat 6509 VSS.

Steve Wood · ‎01-08-2017

Thank you Gurpreet for this nugget the issue just hit me on a 2960XR stack running 15.2(2)E5

bberry · ‎03-04-2019

I just has this same issue hit my core switch ...

Switch Ports Model SW Version SW Image Mode
------ ----- ----- ---------- ---------- ----
* 1 52 WS-C3650-48PS 03.06.06E cat3k_caa-universalk9 INSTALL

Issued the command in my config and everything started running on all cylinders again .. Now just need to see if I can find a root cause that made this happen. Something had to start this process.Anyone have any thoughts?

Brent

rajbharg · ‎09-01-2019

solved thanks for this post.