Thanks Tung.
Please find my response inline.
Thanks and regards,
Prakash
On Tue, Apr 18, 2023 at 7:04 AM Tung Quang Nguyen <
tung.q.ngu...@dektech.com.au> wrote:
>
>
>
>
> *From:* prakash bisht <ps13.bi...@gmail.com>
> *Sent:* Monday, April 17, 2023 11:20 AM
> *To:* tipc-discussion@lists.sourceforge.net; Xin Long <l...@redhat.com>;
> Tung Quang Nguyen <tung.q.ngu...@dektech.com.au>; jma...@redhat.com
> *Subject:* Fwd: TIPC socket ( SOCK_SEQPACKET) cleanup issue
>
>
>
> Hi John/Xin,Tung,
>
>
>
> Any thoughts on my previous email? We are using tipc for our product for
> quite a while and started facing this issue recently in a specific scenario
> we launch strace to monitor another process.
>
> Also is there any way to deny creation of another tipc socket with the
> same tipc address ? In our case applications need a unique tipc server
> socket.
>
> >>> There is no limitation for creating many sockets binding to the same
> tipc address. Why you need “a unique tipc server socket” ? Can you provide
> your code to demonstrate your use case ?
>
> *[Prakash]* We have services which are unique in our system and not meant
> for load balancing. Each service is uniquely represented by a tipc service
> address(type,instance). What we are looking for is that if someone by
> mistake creates a second Service using the same address(type,instance) then
> the service creation fail and throw an error. This is just to avoid a
> silent failure.
>
>
>
> Thanks and Regards,
>
> Prakash
>
> ---------- Forwarded message ---------
> From: *prakash bisht* <ps13.bi...@gmail.com>
> Date: Mon, Apr 3, 2023 at 4:33 PM
> Subject: TIPC socket ( SOCK_SEQPACKET) cleanup issue
> To: <tipc-discussion@lists.sourceforge.net>
>
>
>
> Hi all,
>
>
>
> I am facing an issue while closing the TIPC server socket. In certain
> scenarios, even after closing the server socket fd the ‘tipc socket list’
> is still showing it as alive.
>
> >>> What is you iproute2 version ? Can you provide your code to
> demonstrate your use case ?
>
> *[Prakash ]* We are using iproute2 version-4.20.0-2+deb10u1 on amd64
> platform. Our use case is very simple. We are creating/destroying a server
> socket based on some event using below code.
>
// server socket creation
int sd = socket(AF_TIPC, SOCK_SEQPACKET, 0);
// Closing server socket
close(sd);
After closing the socket the file descriptor is freed but the tipc
socket is still present in "tipc socket list" output.
We have multiple applications in our system which are using tipc
sockets. But we see this behaviour(stale tipc socket) only in one
application.
The only difference which I can notice is that this particular
application is spawning "strace" to monitor some other application. I am
not sure but it looks like somehow running strace is affecting tipc socket
cleanup.
> I am sure that the fd has been closed as the next socket creation request
> gets the same fd from linux. Even when the process exits, the stale socket
> entry is still present in the ‘tipc socket list’ and it vanishes only after
> rebooting the system.
>
> Kernel version : 4.19.81
>
> Socket type : SOCK_SEQPACKET
>
>
>
> Also, is there any way of finding out whether a tipc socket belongs to
> which linux process ?
>
> >>> There is no command to know which tipc socket belongs to which Linux
> process. But you can use function getsockname() to print out the port id
> after creating a socket. Then you know the created socket belongs to the
> calling process.
>
[
> *[Prakash]* Thanks. getsockname() should server the purpose here.
>
> Would appreciate any help.
>
>
>
> Thanks,
>
> Prakash
>
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
