On 5/18/16 9:47 PM, Eric Dumazet wrote:
On Wed, 2016-05-18 at 21:02 -0600, David Ahern wrote:
On 5/18/16 6:55 PM, Lorenzo Colitti wrote:
On Wed, May 18, 2016 at 3:35 AM, <subas...@codeaurora.org> wrote:
Would it be acceptable to have a separate column which displays the result of
the sock destroy operation per socket.
State ... Killed
ESTAB Y
TIME_WAIT N
Fine by me, but... what problem are we trying to address? People who
compile their own kernels and don't turn CONFIG_INET_DIAG_DESTROY, and
then are confused why it doesn't work? Seems like we could fix that by
turning CONFIG_INET_DIAG_DESTROY on by default. CCing the people who
commented on the original SOCK_DESTROY patch to see if they have
opinions.
The problem is proper feedback to a user. If the kernel supports an
action but the action is not enabled the user should get some message to
that fact. Doing nothing and exiting 0 is just wrong.
So, lets say the filter found 123456 sockets matching the filter, and
12345 could be killed
What would be exit status of ss command ?
Again, I could care less if the exit status is 0 if the user is given "A
request failed b/c operations is not supported" message. That is feedback.
In this case, there is no black/white answer.
It looks like you have specific needs, you should probably add an option
to ss to have a specific behavior.
But saying current behavior is 'wrong' is subjective.
You think it is ok to send a request to the kernel, the kernel says "I
can't do it" and the command says nothing to the user? That is current
behavior. How on Earth is that acceptable?
I believe my last proposal is that that user gets a single "I could not
do what you asked" message and nice little summary:
N sockets closed
M sockets failed
If M = total number of sockets then perhaps there is a bigger problem --
like a config option is not enabled.
