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

[Thomas Markwalder]

On 2/12/16 3:13 PM, Thomas Markwalder wrote:
> 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
>
>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
The code snippet above is slightly wrong (I've been mucking with it),
here is the pristine code:

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 == boost::asio::error::would_block
        || ec == 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;
  }
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20160212/5f351c5f/attachment.htm>