Linux kernel does not handle orphaned sockets, why not?
This was originally posted to serverfault but was voted as off topic by the community.
Let me just preface this question by mentioning I understand the why/how/where/when of the Linux kernel socket states, and I wish to force the Linux kernel to behave a certain way for my specific application and context.
Machine is a Pi 3 B+ running Raspbian.
My goal here is to follow the answer from this question to kill sockets that are in a "useless state"*, so I implemented it in Python like so:
def kill_hanging_sockets(self):
default_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
subprocess.call(['sudo bash -c "echo 0 > /proc/sys/net/ipv4/tcp_max_orphans"'], shell=True)
new_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
print('new value is {}'.format(new_max_tcp_sockets))
time.sleep(3)
subprocess.call(['sudo bash -c "echo %s > /proc/sys/net/ipv4/tcp_max_orphans"' % default_max_tcp_sockets], shell=True)
The function is pretty simple, it just sets the value to 0 and prints the value to make sure it's 0, waits three seconds to let the kernel "kill" the orphaned sockets, then sets the max parameter back to its' original value.
However, it's not working, the sockets are not "killed" by the kernel like I presumed they would be. It seems the behavior remains the same and the socket is "killed" within 20 seconds or so; I think changing max_tcp_orpahns either doesn't affect the system, or the socket(s) in question don't truly become orphan socket.
I check the socket(s) using sudo netstat --inet -p -c and they're still there in their FIN_WAIT or CLOSE_WAIT states, which I'm trying to stop from happening. Is there something else I could try here or am I barking up the wrong tree?
[*] my definition of "useless state" may differ from yours, or the Linux kernel's, but please take into consideration the context of the question. In said context the sockets are "useless" to me because I cannot bind another socket until they disappear.
linux-kernel raspberry-pi raspbian socket
asked Dec 20 '18 at 17:54
star_trac
63
|
show 3 more comments
This was originally posted to serverfault but was voted as off topic by the community.
Let me just preface this question by mentioning I understand the why/how/where/when of the Linux kernel socket states, and I wish to force the Linux kernel to behave a certain way for my specific application and context.
Machine is a Pi 3 B+ running Raspbian.
My goal here is to follow the answer from this question to kill sockets that are in a "useless state"*, so I implemented it in Python like so:
def kill_hanging_sockets(self):
default_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
subprocess.call(['sudo bash -c "echo 0 > /proc/sys/net/ipv4/tcp_max_orphans"'], shell=True)
new_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
print('new value is {}'.format(new_max_tcp_sockets))
time.sleep(3)
subprocess.call(['sudo bash -c "echo %s > /proc/sys/net/ipv4/tcp_max_orphans"' % default_max_tcp_sockets], shell=True)
The function is pretty simple, it just sets the value to 0 and prints the value to make sure it's 0, waits three seconds to let the kernel "kill" the orphaned sockets, then sets the max parameter back to its' original value.
However, it's not working, the sockets are not "killed" by the kernel like I presumed they would be. It seems the behavior remains the same and the socket is "killed" within 20 seconds or so; I think changing max_tcp_orpahns either doesn't affect the system, or the socket(s) in question don't truly become orphan socket.
I check the socket(s) using sudo netstat --inet -p -c and they're still there in their FIN_WAIT or CLOSE_WAIT states, which I'm trying to stop from happening. Is there something else I could try here or am I barking up the wrong tree?
[*] my definition of "useless state" may differ from yours, or the Linux kernel's, but please take into consideration the context of the question. In said context the sockets are "useless" to me because I cannot bind another socket until they disappear.
linux-kernel raspberry-pi raspbian socket
asked Dec 20 '18 at 17:54
star_trac
63
Well, yes. The question isn't about server administration in a professional environment, so ServerFault will have bounced it. TBH I'm not sure it's on-topic here either.
– roaima
Dec 20 '18 at 22:43
Are you creating a server and are finding issuesbind()ing to the address on a restart? If so, useSO_REUSEADDRso that the old sockets in fin/close state don't prevent a new server process from listening.
– Stephen Harris
Dec 20 '18 at 23:03
@roaima where is it on-topic? I felt like Unix & Linux would be an ideal place for discussion around Linux sockets.
– star_trac
Dec 20 '18 at 23:29
@StephenHarris thanks, yes I'm usingSO_REUSEADDRwhen creating the server socket.
– star_trac
Dec 20 '18 at 23:32
(1) Please state your objective clearly, up front. Don’t make people jump to a footnote and read between the lines. (2) Are you asking a Why? question or a How do I do X? question? Make sure that the question title and the question body are asking the same question. … … … … … … Please do not respond in comments; edit your question to make it clearer and more complete.
– Scott
Dec 22 '18 at 4:15
|
show 3 more comments
This was originally posted to serverfault but was voted as off topic by the community.
Let me just preface this question by mentioning I understand the why/how/where/when of the Linux kernel socket states, and I wish to force the Linux kernel to behave a certain way for my specific application and context.
Machine is a Pi 3 B+ running Raspbian.
My goal here is to follow the answer from this question to kill sockets that are in a "useless state"*, so I implemented it in Python like so:
def kill_hanging_sockets(self):
default_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
subprocess.call(['sudo bash -c "echo 0 > /proc/sys/net/ipv4/tcp_max_orphans"'], shell=True)
new_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
print('new value is {}'.format(new_max_tcp_sockets))
time.sleep(3)
subprocess.call(['sudo bash -c "echo %s > /proc/sys/net/ipv4/tcp_max_orphans"' % default_max_tcp_sockets], shell=True)
The function is pretty simple, it just sets the value to 0 and prints the value to make sure it's 0, waits three seconds to let the kernel "kill" the orphaned sockets, then sets the max parameter back to its' original value.
However, it's not working, the sockets are not "killed" by the kernel like I presumed they would be. It seems the behavior remains the same and the socket is "killed" within 20 seconds or so; I think changing max_tcp_orpahns either doesn't affect the system, or the socket(s) in question don't truly become orphan socket.
I check the socket(s) using sudo netstat --inet -p -c and they're still there in their FIN_WAIT or CLOSE_WAIT states, which I'm trying to stop from happening. Is there something else I could try here or am I barking up the wrong tree?
[*] my definition of "useless state" may differ from yours, or the Linux kernel's, but please take into consideration the context of the question. In said context the sockets are "useless" to me because I cannot bind another socket until they disappear.
linux-kernel raspberry-pi raspbian socket
asked Dec 20 '18 at 17:54
star_trac
63
This was originally posted to serverfault but was voted as off topic by the community.
Let me just preface this question by mentioning I understand the why/how/where/when of the Linux kernel socket states, and I wish to force the Linux kernel to behave a certain way for my specific application and context.
Machine is a Pi 3 B+ running Raspbian.
My goal here is to follow the answer from this question to kill sockets that are in a "useless state"*, so I implemented it in Python like so:
def kill_hanging_sockets(self):
default_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
subprocess.call(['sudo bash -c "echo 0 > /proc/sys/net/ipv4/tcp_max_orphans"'], shell=True)
new_max_tcp_sockets = subprocess.check_output(['cat /proc/sys/net/ipv4/tcp_max_orphans'], shell=True)
print('new value is {}'.format(new_max_tcp_sockets))
time.sleep(3)
subprocess.call(['sudo bash -c "echo %s > /proc/sys/net/ipv4/tcp_max_orphans"' % default_max_tcp_sockets], shell=True)
The function is pretty simple, it just sets the value to 0 and prints the value to make sure it's 0, waits three seconds to let the kernel "kill" the orphaned sockets, then sets the max parameter back to its' original value.
However, it's not working, the sockets are not "killed" by the kernel like I presumed they would be. It seems the behavior remains the same and the socket is "killed" within 20 seconds or so; I think changing max_tcp_orpahns either doesn't affect the system, or the socket(s) in question don't truly become orphan socket.
I check the socket(s) using sudo netstat --inet -p -c and they're still there in their FIN_WAIT or CLOSE_WAIT states, which I'm trying to stop from happening. Is there something else I could try here or am I barking up the wrong tree?
[*] my definition of "useless state" may differ from yours, or the Linux kernel's, but please take into consideration the context of the question. In said context the sockets are "useless" to me because I cannot bind another socket until they disappear.
linux-kernel raspberry-pi raspbian socket
linux-kernel raspberry-pi raspbian socket
asked Dec 20 '18 at 17:54
star_trac
63
asked Dec 20 '18 at 17:54
star_trac
63
asked Dec 20 '18 at 17:54
star_trac
63
asked Dec 20 '18 at 17:54
star_trac
63
asked Dec 20 '18 at 17:54
star_trac
63
63
Well, yes. The question isn't about server administration in a professional environment, so ServerFault will have bounced it. TBH I'm not sure it's on-topic here either.
– roaima
Dec 20 '18 at 22:43
Are you creating a server and are finding issuesbind()ing to the address on a restart? If so, useSO_REUSEADDRso that the old sockets in fin/close state don't prevent a new server process from listening.
– Stephen Harris
Dec 20 '18 at 23:03
@roaima where is it on-topic? I felt like Unix & Linux would be an ideal place for discussion around Linux sockets.
– star_trac
Dec 20 '18 at 23:29
@StephenHarris thanks, yes I'm usingSO_REUSEADDRwhen creating the server socket.
– star_trac
Dec 20 '18 at 23:32
(1) Please state your objective clearly, up front. Don’t make people jump to a footnote and read between the lines. (2) Are you asking a Why? question or a How do I do X? question? Make sure that the question title and the question body are asking the same question. … … … … … … Please do not respond in comments; edit your question to make it clearer and more complete.
– Scott
Dec 22 '18 at 4:15
|
show 3 more comments
Well, yes. The question isn't about server administration in a professional environment, so ServerFault will have bounced it. TBH I'm not sure it's on-topic here either.
– roaima
Dec 20 '18 at 22:43
Are you creating a server and are finding issuesbind()ing to the address on a restart? If so, useSO_REUSEADDRso that the old sockets in fin/close state don't prevent a new server process from listening.
– Stephen Harris
Dec 20 '18 at 23:03
@roaima where is it on-topic? I felt like Unix & Linux would be an ideal place for discussion around Linux sockets.
– star_trac
Dec 20 '18 at 23:29
@StephenHarris thanks, yes I'm usingSO_REUSEADDRwhen creating the server socket.
– star_trac
Dec 20 '18 at 23:32
(1) Please state your objective clearly, up front. Don’t make people jump to a footnote and read between the lines. (2) Are you asking a Why? question or a How do I do X? question? Make sure that the question title and the question body are asking the same question. … … … … … … Please do not respond in comments; edit your question to make it clearer and more complete.
– Scott
Dec 22 '18 at 4:15
Well, yes. The question isn't about server administration in a professional environment, so ServerFault will have bounced it. TBH I'm not sure it's on-topic here either.
– roaima
Dec 20 '18 at 22:43
Well, yes. The question isn't about server administration in a professional environment, so ServerFault will have bounced it. TBH I'm not sure it's on-topic here either.
– roaima
Dec 20 '18 at 22:43
Are you creating a server and are finding issues
bind()ing to the address on a restart? If so, use SO_REUSEADDR so that the old sockets in fin/close state don't prevent a new server process from listening.– Stephen Harris
Dec 20 '18 at 23:03
Are you creating a server and are finding issues
bind()ing to the address on a restart? If so, use SO_REUSEADDR so that the old sockets in fin/close state don't prevent a new server process from listening.– Stephen Harris
Dec 20 '18 at 23:03
@roaima where is it on-topic? I felt like Unix & Linux would be an ideal place for discussion around Linux sockets.
– star_trac
Dec 20 '18 at 23:29
@roaima where is it on-topic? I felt like Unix & Linux would be an ideal place for discussion around Linux sockets.
– star_trac
Dec 20 '18 at 23:29
@StephenHarris thanks, yes I'm using
SO_REUSEADDR when creating the server socket.– star_trac
Dec 20 '18 at 23:32
@StephenHarris thanks, yes I'm using
SO_REUSEADDR when creating the server socket.– star_trac
Dec 20 '18 at 23:32
(1) Please state your objective clearly, up front. Don’t make people jump to a footnote and read between the lines. (2) Are you asking a Why? question or a How do I do X? question? Make sure that the question title and the question body are asking the same question. … … … … … … Please do not respond in comments; edit your question to make it clearer and more complete.
– Scott
Dec 22 '18 at 4:15
(1) Please state your objective clearly, up front. Don’t make people jump to a footnote and read between the lines. (2) Are you asking a Why? question or a How do I do X? question? Make sure that the question title and the question body are asking the same question. … … … … … … Please do not respond in comments; edit your question to make it clearer and more complete.
– Scott
Dec 22 '18 at 4:15
|
show 3 more comments
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f490167%2flinux-kernel-does-not-handle-orphaned-sockets-why-not%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f490167%2flinux-kernel-does-not-handle-orphaned-sockets-why-not%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Well, yes. The question isn't about server administration in a professional environment, so ServerFault will have bounced it. TBH I'm not sure it's on-topic here either.
– roaima
Dec 20 '18 at 22:43
Are you creating a server and are finding issues
bind()ing to the address on a restart? If so, useSO_REUSEADDRso that the old sockets in fin/close state don't prevent a new server process from listening.– Stephen Harris
Dec 20 '18 at 23:03
@roaima where is it on-topic? I felt like Unix & Linux would be an ideal place for discussion around Linux sockets.
– star_trac
Dec 20 '18 at 23:29
@StephenHarris thanks, yes I'm using
SO_REUSEADDRwhen creating the server socket.– star_trac
Dec 20 '18 at 23:32
(1) Please state your objective clearly, up front. Don’t make people jump to a footnote and read between the lines. (2) Are you asking a Why? question or a How do I do X? question? Make sure that the question title and the question body are asking the same question. … … … … … … Please do not respond in comments; edit your question to make it clearer and more complete.
– Scott
Dec 22 '18 at 4:15