[Kea-users] DHCP-DDNS server repeatedly logging "Resource temporarily unavailable"

Thomas Markwalder tmark at isc.org
Fri Feb 12 20:13:23 UTC 2016


On 2/4/16 6:26 PM, Derek Lambert wrote:
> If it helps here's a strace of the server without optimizations, it
> just waits in the last call to epoll_wait. I gave it 5 minutes before
> killing it:
>
: removed for brevity...
>
>     > Thanks for the tip! This will at least allow me to move forward with my
>     > testing.
>     Thanks for sharing the results. Ok, so it seems this issue occurring
>     when Kea is built with gcc 5 and optimizations are enabled. Hopefully
>     that piece of information will be useful in debugging.
>
>     Tomek
>
>
>
>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
Hello all:

After some rather painful debugging, we have isolated the issue to a
boost::asio function from which the gcc optimizer is incorrectly
removing some critical checks:


(from the source file: /usr/include/boost/asio/detail/impl/socket_ops.ipp)

 :
bool non_blocking_recvfrom(socket_type s,
    buf* bufs, size_t count, int flags,
    socket_addr_type* addr, std::size_t* addrlen,
    boost::system::error_code& ec, size_t& bytes_transferred)
{
  for (;;)
  {
    // Read some data.
    signed_size_type bytes = socket_ops::recvfrom(
        s, bufs, count, flags, addr, addrlen, ec);

    // Retry operation if interrupted by signal.
    if (ec == boost::asio::error::interrupted)
      continue;

    // Check if we need to run the operation again.
    if (ec_local == boost::asio::error::would_block
        || ec_local == boost::asio::error::try_again)
      return false;

    // Operation is complete.
    if (bytes >= 0)
    {
      ec = boost::system::error_code();
      bytes_transferred = bytes;
    }
    else
      bytes_transferred = 0;

    return true;
  }
}
   :

The checks against the value of "ec" after the call to "recvfrom()" are
optimized out causing the function to always return true, even if the
read was interrupted (should continue) or the call would block (should
return false).  In either case, the true return causes the callback
registered to the socket to be invoked when it should not be.  The
DHCP_DDNS library code interprets this as a failed read.

This manifests itself in D2 as an infinite loop of failed reads.  I'll
be opening up an issue the GCC folks as well as coming up with a
short-term solution, which will likely turn off optimization for the
asio code.

There is Trac ticket associated with this already,
http://kea.isc.org/ticket/4243.


Thomas Markwalder
ISC Software Engineering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20160212/87479c95/attachment.htm>


More information about the Kea-users mailing list