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.
If it is not supported from kernel, maybe print U (unsupported) for this.
In current code there is no way to distinguish U from N because in
both cases the error will be EOPNOTSUPP. It's certainly possible to
change SOCK_DESTROY to return something else (e.g., EBADFD) to
indicate "kernel supports closing this type of socket, but it can't be
closed due to the state it's in". In hindsight, perhaps I should have
done that from the start.
Regardless, we still have the problem of what to do if the user says
"ss -K dport = :443" and we encounter a UDP socket connected to port
443. Options:
1. Silently skip. if the tool prints something, it means it closed it.
2. Abort with an error message.
3. Skip the socket and print an error every time this happens.
4. Skip the socket and print an error the first time this happens.
Personally I still think #1 is the best option.
5. Print an error the first time and a summary at the end.
If the filter matches N sockets and all N fail with UNSUPPORTED give the
user a message saying that all failed due to unsupported error which
could mean the CONFIG option is not enabled or it could mean the sockets
can not be forced closed.
