HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- blocking in socket close
Operating System - HP-UX
1833750
Members
3379
Online
110063
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-28-2005 09:58 PM
09-28-2005 09:58 PM
blocking in socket close
Hey all,
My applications are run on HP 10.20. They are connected Socket.
when lan cable pull out , the application are hang in close() system call, like this
(gdb) where
#0 0xc013e920 in _close_sys () from /usr/lib/libc.1
#1 0xc0149230 in close () from /usr/lib/libc.1
#2 0x1dcd0 in libSockShutdownSockFd (fd=17) at Sock_socket.c:699
#3 0x1db80 in libSockClose (fdInfoPtr=0x401502b8) at Sock_socket.c:663
#4 0x1b8cc in libESockRecvTimerExpired (timerInfo=0x40150a58) at Sock_extern.c:146
#5 0x1ff00 in libSockChkTimer () at Sock_timer.c:187
#6 0x196e4 in libSockEventHandler (n=0, rdMask=0x7b03acb0, wrMask=0x7b03adb0, exMask=0x7b03aeb0, timeOut=0x7b03afb0)
As I know, close() returns immediately. But the application is blocking.
I set l_onoff=1, l_linger=0 using setsockopt().
My applications are run on HP 10.20. They are connected Socket.
when lan cable pull out , the application are hang in close() system call, like this
(gdb) where
#0 0xc013e920 in _close_sys () from /usr/lib/libc.1
#1 0xc0149230 in close () from /usr/lib/libc.1
#2 0x1dcd0 in libSockShutdownSockFd (fd=17) at Sock_socket.c:699
#3 0x1db80 in libSockClose (fdInfoPtr=0x401502b8) at Sock_socket.c:663
#4 0x1b8cc in libESockRecvTimerExpired (timerInfo=0x40150a58) at Sock_extern.c:146
#5 0x1ff00 in libSockChkTimer () at Sock_timer.c:187
#6 0x196e4 in libSockEventHandler (n=0, rdMask=0x7b03acb0, wrMask=0x7b03adb0, exMask=0x7b03aeb0, timeOut=0x7b03afb0)
As I know, close() returns immediately. But the application is blocking.
I set l_onoff=1, l_linger=0 using setsockopt().
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-30-2005 04:28 AM
09-30-2005 04:28 AM
Re: blocking in socket close
Regardless of blocking or not, setting l_onoff=1 and l_linger=0 is badnews - it can lead to an abortive close of the connection rather than a graceful one. Abortive closes are bad.
So, instead of setting SO_LINGER, why not leave it unset - l_onoff = 0 and leave it at that. From the setsockopt manpage:
SO_LINGER controls the actions to be taken when there are
untransmitted data in a SOCK_STREAM send socket buffer when the socket
is closed, either due to an explicit call to close() or because the
application terminates normally or abnormally. The action is
determined by the values of members of the struct linger data
structure pointed to by optval in a call to setsockopt(). The data
type struct linger is defined in. If l_onoff is zero
(the default action), close() returns immediately, but the system
tries to transmit any unsent data and release the protocol connection
gracefully. If l_onoff is non-zero and l_linger is zero, close()
returns immediately, any unsent data is discarded, and the protocol
connection is aborted. If both l_onoff and l_linger are non-zero,
close() does not return until the system has tried to transmit all
unsent data and release the connection gracefully.
So, instead of setting SO_LINGER, why not leave it unset - l_onoff = 0 and leave it at that. From the setsockopt manpage:
SO_LINGER controls the actions to be taken when there are
untransmitted data in a SOCK_STREAM send socket buffer when the socket
is closed, either due to an explicit call to close() or because the
application terminates normally or abnormally. The action is
determined by the values of members of the struct linger data
structure pointed to by optval in a call to setsockopt(). The data
type struct linger is defined in
(the default action), close() returns immediately, but the system
tries to transmit any unsent data and release the protocol connection
gracefully. If l_onoff is non-zero and l_linger is zero, close()
returns immediately, any unsent data is discarded, and the protocol
connection is aborted. If both l_onoff and l_linger are non-zero,
close() does not return until the system has tried to transmit all
unsent data and release the connection gracefully.
there is no rest for the wicked yet the virtuous have no pillows
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP