<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: ENOBUFS ERROR in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556170#M593877</link>
    <description>Hi,&lt;BR /&gt;&lt;BR /&gt;This has been replied to previously.  &lt;BR /&gt;Here's some technical details.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;-&amp;gt; Brian Hackley&lt;BR /&gt;&lt;BR /&gt;Why 11.0 accept() can cause ENOBUFS?&lt;BR /&gt;====================================&lt;BR /&gt;The description has not been changed at 11.0. However, the implementation of accept() system call was changed at 11.0(Transport stack has changed drastically due to STREAMS based TCP/IP).   And it can return -1 with&lt;BR /&gt;errno=ENOBUFS based on the condition of "the queued socket connect request is aborted". Here, this means the transport stack received RST just after SYN was received. If RST comes&lt;BR /&gt;before accept() is done, this situation can happen.&lt;BR /&gt;&lt;BR /&gt;On 10.X, if this happens, the connection was just silently dropped.&lt;BR /&gt;&lt;BR /&gt;How this error should be handled ?&lt;BR /&gt;==================================&lt;BR /&gt;If this can be seen with existing application, just ignore the error. Since this can happen when we receive RST just after SYN, the connection request is anyway cancelled.&lt;BR /&gt;There should be no serious problem.&lt;BR /&gt;&lt;BR /&gt;If the application aborts with this error situation, it should be re-written so that it will retry accept() system call. ENOBUFS is usually indicating transient error. So,&lt;BR /&gt;aborting the application just by seeing this error once should not be proper action. The application should be modified so that it gets more robustness.&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Tue, 31 Jul 2001 14:56:48 GMT</pubDate>
    <dc:creator>Brian Hackley</dc:creator>
    <dc:date>2001-07-31T14:56:48Z</dc:date>
    <item>
      <title>ENOBUFS ERROR</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556167#M593874</link>
      <description>can anyone here help me with my problem.  i am getting an ENOBUFS error with the accept function.  what does this mean?  what system resource is it referring to?  &lt;BR /&gt;&lt;BR /&gt;i have checked the internet and most info i get say that ENOBUFS occur in UDP writing to sockets and that it occurs when mbufs is exhausted.  can anyone tell me what is this mbufs?&lt;BR /&gt;&lt;BR /&gt;btw, i am working on a HP-UX HP Visualize 9000/785/B2000.&lt;BR /&gt;&lt;BR /&gt;please advise me.  thanks a lot.</description>
      <pubDate>Tue, 24 Jul 2001 08:21:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556167#M593874</guid>
      <dc:creator>Alexander Ongelico</dc:creator>
      <dc:date>2001-07-24T08:21:35Z</dc:date>
    </item>
    <item>
      <title>Re: ENOBUFS ERROR</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556168#M593875</link>
      <description>Hi &lt;BR /&gt;&lt;BR /&gt;you can check the mbufs with : &lt;BR /&gt;&lt;BR /&gt;      /etc/netstat -T or tcpstat -T&lt;BR /&gt;&lt;BR /&gt;and check the following parameters;&lt;BR /&gt;&lt;BR /&gt;     33/336 mbufs in use:&lt;BR /&gt;        3/112 (  80-byte) mbufs used/allocated&lt;BR /&gt;       30/112 (1560-byte) mbufs used/allocated&lt;BR /&gt;   0/112 (9216-byte) mbufs used/allocated&lt;BR /&gt;     1187 Kbytes allocated to network (3% in use)&lt;BR /&gt;     0 requests for memory denied&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;and you can read about the mbufs in this link :&lt;BR /&gt;&lt;A href="http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90666/B2355-90666_top.html&amp;amp;con=/hpux/onlinedocs/B2355-90666/00/00/58-con.html&amp;amp;toc=/hpux/onlinedocs/B2355-90666/00/00/58-toc.html&amp;amp;searchterms=mbufs&amp;amp;queryid=20010724-031020" target="_blank"&gt;http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90666/B2355-90666_top.html&amp;amp;con=/hpux/onlinedocs/B2355-90666/00/00/58-con.html&amp;amp;toc=/hpux/onlinedocs/B2355-90666/00/00/58-toc.html&amp;amp;searchterms=mbufs&amp;amp;queryid=20010724-031020&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;and you are rigth all the docs that i check is telling to check the zie of the mbufs .&lt;BR /&gt;&lt;BR /&gt;also you need to install the 100bt patch ( if this the card taht you are working with ) &lt;BR /&gt;</description>
      <pubDate>Tue, 24 Jul 2001 09:12:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556168#M593875</guid>
      <dc:creator>eran maor</dc:creator>
      <dc:date>2001-07-24T09:12:39Z</dc:date>
    </item>
    <item>
      <title>Re: ENOBUFS ERROR</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556169#M593876</link>
      <description>i am going to guess that you are running hp-ux 11. on that stack, it is possible for accept to return enobufs when the client side closes the connection before the server calls accept. enobufs was used instead of a new errno return from accept() because it already existed and was a non-fatal error. after an enobufs the linsten endpoint is still good and is still useable for incoming connections.&lt;BR /&gt;&lt;BR /&gt;i suspect it has nothing to do with mbufs. in no small part because the HP-UX 11 networking stack does not use mbufs. it uses mblks :)</description>
      <pubDate>Tue, 24 Jul 2001 19:33:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556169#M593876</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2001-07-24T19:33:48Z</dc:date>
    </item>
    <item>
      <title>Re: ENOBUFS ERROR</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556170#M593877</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;This has been replied to previously.  &lt;BR /&gt;Here's some technical details.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;-&amp;gt; Brian Hackley&lt;BR /&gt;&lt;BR /&gt;Why 11.0 accept() can cause ENOBUFS?&lt;BR /&gt;====================================&lt;BR /&gt;The description has not been changed at 11.0. However, the implementation of accept() system call was changed at 11.0(Transport stack has changed drastically due to STREAMS based TCP/IP).   And it can return -1 with&lt;BR /&gt;errno=ENOBUFS based on the condition of "the queued socket connect request is aborted". Here, this means the transport stack received RST just after SYN was received. If RST comes&lt;BR /&gt;before accept() is done, this situation can happen.&lt;BR /&gt;&lt;BR /&gt;On 10.X, if this happens, the connection was just silently dropped.&lt;BR /&gt;&lt;BR /&gt;How this error should be handled ?&lt;BR /&gt;==================================&lt;BR /&gt;If this can be seen with existing application, just ignore the error. Since this can happen when we receive RST just after SYN, the connection request is anyway cancelled.&lt;BR /&gt;There should be no serious problem.&lt;BR /&gt;&lt;BR /&gt;If the application aborts with this error situation, it should be re-written so that it will retry accept() system call. ENOBUFS is usually indicating transient error. So,&lt;BR /&gt;aborting the application just by seeing this error once should not be proper action. The application should be modified so that it gets more robustness.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 31 Jul 2001 14:56:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/enobufs-error/m-p/2556170#M593877</guid>
      <dc:creator>Brian Hackley</dc:creator>
      <dc:date>2001-07-31T14:56:48Z</dc:date>
    </item>
  </channel>
</rss>

