• Multiple processes listening on the same port.

    From hongyi.zhao@gmail.com@21:1/5 to All on Sun Feb 26 00:47:01 2023
    On my computer, I noticed the following processes information:

    $ pgrep -af f4f4a488c740adc8
    3423257 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1487_f4f4a488c740adc80e1e4c43d81a14da.json -l 10014
    3423263 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1487_f4f4a488c740adc80e1e4c43d81a14da.json -l 10014

    As you can see, there are two processes listening on the same port. On the other hand, if I kill one of them, both will be terminated. Why do these processes work this way? Why are they listening on the same port at the same time? Any tips for this
    behavior will be appreciated.

    Regards,
    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kees Nuyt@21:1/5 to hongyi.zhao@gmail.com on Sun Feb 26 16:14:13 2023
    On Sun, 26 Feb 2023 00:47:01 -0800 (PST), "hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:

    On my computer, I noticed the following processes information:

    $ pgrep -af f4f4a488c740adc8
    3423257 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1487_f4f4a488c740adc80e1e4c43d81a14da.json -l 10014
    3423263 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1487_f4f4a488c740adc80e1e4c43d81a14da.json -l 10014

    As you can see, there are two processes listening
    on the same port. On the other hand, if I kill
    one of them, both will be terminated.

    This pgrep output does not prove these sslocal processes are
    listening on the same port. It just says they are started with
    the same -l parameter.

    Two processes _can_ listen on the same portnumber on _different
    interfaces_.

    Why do these processes work this way?
    Why are they listening on the same port at the same time?

    You'll have to study the documentation of sslocal, and/or ask
    the author(s).

    --
    Kees Nuyt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to Kees Nuyt on Sun Feb 26 07:46:20 2023
    On Sunday, February 26, 2023 at 11:14:21 PM UTC+8, Kees Nuyt wrote:
    On Sun, 26 Feb 2023 00:47:01 -0800 (PST), "hongy...@gmail.com" <hongy...@gmail.com> wrote:

    On my computer, I noticed the following processes information:

    $ pgrep -af f4f4a488c740adc8
    3423257 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1487_f4f4a488c740adc80e1e4c43d81a14da.json -l 10014
    3423263 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1487_f4f4a488c740adc80e1e4c43d81a14da.json -l 10014

    As you can see, there are two processes listening
    on the same port. On the other hand, if I kill
    one of them, both will be terminated.
    This pgrep output does not prove these sslocal processes are
    listening on the same port. It just says they are started with
    the same -l parameter.

    Two processes _can_ listen on the same portnumber on _different
    interfaces_.

    What might be the purpose of this? Can you give some similar examples?

    Why do these processes work this way?
    Why are they listening on the same port at the same time?
    You'll have to study the documentation of sslocal, and/or ask
    the author(s).

    --
    Kees Nuyt

    Best,
    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kees Nuyt@21:1/5 to hongyi.zhao@gmail.com on Mon Feb 27 03:10:24 2023
    On Sun, 26 Feb 2023 07:46:20 -0800 (PST), "hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:

    Kees Nuyt wrote:
    Two processes _can_ listen on the same portnumber on _different
    interfaces_.

    What might be the purpose of this? Can you give some similar examples?

    I have no idea, but it is possible.
    Check with
    sudo netstat -lntp
    what your sslocal processes are actually doing.
    --
    Kees Nuyt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to Kees Nuyt on Mon Feb 27 00:15:48 2023
    On Monday, February 27, 2023 at 10:10:31 AM UTC+8, Kees Nuyt wrote:
    On Sun, 26 Feb 2023 07:46:20 -0800 (PST), "hongy...@gmail.com" <hongy...@gmail.com> wrote:
    Kees Nuyt wrote:
    Two processes _can_ listen on the same portnumber on _different
    interfaces_.

    What might be the purpose of this? Can you give some similar examples?
    I have no idea, but it is possible.
    Check with
    sudo netstat -lntp
    what your sslocal processes are actually doing.

    See the following:

    werner@X10DAi:~$ sudo apt install net-tools
    werner@X10DAi:~$ sudo netstat -lntp |grep 10014
    tcp 0 0 0.0.0.0:10014 0.0.0.0:* LISTEN 239621/sslocal

    In this way, only one process on each port returns in the command result.

    --
    Kees Nuyt

    Regards,
    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gerg@21:1/5 to hongy...@gmail.com on Thu Mar 2 06:37:52 2023
    hongy...@gmail.com <hongyi.zhao@gmail.com> wrote:

    As you can see, there are two processes listening on the same port. On the other hand,
    if I kill one of them, both will be terminated. Why do these processes work this way?
    Why are they listening on the same port at the same time? Any tips for this behavior
    will be appreciated.


    When you examine these two process ids and take into account each one's ppid (parent process id), does it perhaps reveal these are a parent and child process?

    --
    ::::::::::::: Greg Andrews ::::: gerg@panix.com :::::::::::::
    I have a map of the United States that's actual size.
    -- Steven Wright

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to gerg on Thu Mar 2 21:42:50 2023
    On Thursday, March 2, 2023 at 2:37:58 PM UTC+8, gerg wrote:
    hongy...@gmail.com <hongy...@gmail.com> wrote:

    As you can see, there are two processes listening on the same port. On the other hand,
    if I kill one of them, both will be terminated. Why do these processes work this way?
    Why are they listening on the same port at the same time? Any tips for this behavior
    will be appreciated.

    When you examine these two process ids and take into account each one's ppid (parent process id), does it perhaps reveal these are a parent and child process?

    They have the same pgid, sid, and sgid, as shown below:

    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    68311 67948 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    68318 68311 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014


    --
    ::::::::::::: Greg Andrews ::::: ge...@panix.com :::::::::::::
    I have a map of the United States that's actual size.
    -- Steven Wright

    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Fri Mar 3 09:51:16 2023
    Am 26.02.2023 schrieb "hongy...@gmail.com" <hongyi.zhao@gmail.com>:

    As you can see, there are two processes listening on the same port.

    That is possible if they don't use the same IP.
    So 2 different processes can listen on TCP [2001:db::123]:80 and TCP [2001:db::4444]:80.

    Use ss -ltun to find more information.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to Marco Moock on Sat Mar 4 03:51:40 2023
    On Friday, March 3, 2023 at 4:51:22 PM UTC+8, Marco Moock wrote:
    Am 26.02.2023 schrieb "hongy...@gmail.com" <hongy...@gmail.com>:

    As you can see, there are two processes listening on the same port.
    That is possible if they don't use the same IP.
    So 2 different processes can listen on TCP [2001:db::123]:80 and TCP [2001:db::4444]:80.

    Use ss -ltun to find more information.

    See the following for more details:

    werner@X10DAi:~$ ss -ltun | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:*
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:*

    Regards,
    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kees Nuyt@21:1/5 to hongyi.zhao@gmail.com on Sat Mar 4 13:29:01 2023
    On Thu, 2 Mar 2023 21:42:50 -0800 (PST), "hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:


    They have the same pgid, sid, and sgid, as shown below:

    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    68311 67948 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    68318 68311 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014

    So, process 68318 was started by 68311.

    This is a common construct:
    The parent process (68311 in this case) does not handle
    anything, it just spawns a child process (68318). That child
    does the heavy lifting. If the child crashes, the parent spawns
    a new one. In that case the child listens on the port.

    There are other constructs, where the parent listens on the port
    and spawns one or more child ("worker") processes to handle
    incomin requests. The parent just mamages the request queue.

    I don't know what happens here. As I said before, you have to
    consult the sslocal documentation.
    Ok, enough keywords there for you to search for mor elaborate
    descriptions.
    --
    Kees Nuyt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kees Nuyt@21:1/5 to hongyi.zhao@gmail.com on Sat Mar 4 13:36:04 2023
    On Sat, 4 Mar 2023 03:51:40 -0800 (PST), "hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:

    Use ss -ltun to find more information.

    See the following for more details:

    werner@X10DAi:~$ ss -ltun | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:*
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:*

    Now, add the -p option to see if udp and tcp are served by the
    same process:
    sudo ss -ltunp
    --
    Kees Nuyt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to Kees Nuyt on Sat Mar 4 04:45:24 2023
    On Saturday, March 4, 2023 at 8:36:09 PM UTC+8, Kees Nuyt wrote:
    On Sat, 4 Mar 2023 03:51:40 -0800 (PST), "hongy...@gmail.com" <hongy...@gmail.com> wrote:

    Use ss -ltun to find more information.

    See the following for more details:

    werner@X10DAi:~$ ss -ltun | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:*
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:*
    Now, add the -p option to see if udp and tcp are served by the
    same process:
    sudo ss -ltunp

    See the following:

    werner@X10DAi:~$ ss -ltunp | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=4))
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=3))
    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    3123709 3123347 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    3123715 3123709 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014

    --
    Kees Nuyt

    Best,
    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to Kees Nuyt on Sat Mar 4 04:44:07 2023
    On Saturday, March 4, 2023 at 8:29:07 PM UTC+8, Kees Nuyt wrote:
    On Thu, 2 Mar 2023 21:42:50 -0800 (PST), "hongy...@gmail.com" <hongy...@gmail.com> wrote:


    They have the same pgid, sid, and sgid, as shown below:

    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    68311 67948 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    68318 68311 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    So, process 68318 was started by 68311.

    This is a common construct:
    The parent process (68311 in this case) does not handle
    anything, it just spawns a child process (68318). That child
    does the heavy lifting. If the child crashes, the parent spawns
    a new one. In that case the child listens on the port.

    There are other constructs, where the parent listens on the port
    and spawns one or more child ("worker") processes to handle
    incomin requests. The parent just mamages the request queue.

    I don't know what happens here. As I said before, you have to
    consult the sslocal documentation.
    Ok, enough keywords there for you to search for mor elaborate
    descriptions.

    Nice comments and explanations. Thank you very much.

    --
    Kees Nuyt

    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to Kees Nuyt on Sat Mar 4 04:53:01 2023
    On Saturday, March 4, 2023 at 8:29:07 PM UTC+8, Kees Nuyt wrote:
    On Thu, 2 Mar 2023 21:42:50 -0800 (PST), "hongy...@gmail.com" <hongy...@gmail.com> wrote:


    They have the same pgid, sid, and sgid, as shown below:

    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    68311 67948 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    68318 68311 67948 64750 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    So, process 68318 was started by 68311.

    This is a common construct:
    The parent process (68311 in this case) does not handle
    anything, it just spawns a child process (68318). That child
    does the heavy lifting. If the child crashes, the parent spawns
    a new one. In that case the child listens on the port.

    I noticed that if I killed the child process (68318 in this case), both processes will be terminated. I'm not sure whether this is consistent with your above analysis.

    There are other constructs, where the parent listens on the port
    and spawns one or more child ("worker") processes to handle
    incomin requests. The parent just mamages the request queue.

    I don't know what happens here. As I said before, you have to
    consult the sslocal documentation.
    Ok, enough keywords there for you to search for mor elaborate
    descriptions.
    --
    Kees Nuyt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kees Nuyt@21:1/5 to hongyi.zhao@gmail.com on Sun Mar 5 19:01:13 2023
    On Sat, 4 Mar 2023 04:45:24 -0800 (PST), "hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:

    Now, add the -p option to see if udp and tcp are served by the
    same process:
    sudo ss -ltunp

    See the following:

    werner@X10DAi:~$ ss -ltunp | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=4))
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=3))
    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    3123709 3123347 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    3123715 3123709 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014

    Ok, there you are, that's clear. And what does the sslocal docs
    tell you?
    --
    Kees Nuyt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to hongy...@gmail.com on Sun Mar 5 11:53:36 2023
    Port numbers are not the same thing as sockets.

    You can easily have different processes listen to the same port number
    on different protocols (UDP vs TCP) and / or different IPs.

    On 3/4/23 4:51 AM, hongy...@gmail.com wrote:
    werner@X10DAi:~$ ss -ltun | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:*
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:*

    This shows two different sockets. Both are listening on port 10014 on
    all IPs. However one is on UDP and the other is on TCP.

    It is also possible for a process to listen to multiple sockets.

    There are also some provisions to pass a connection on a socket from a
    parent process to a child process.

    I think that there are some VERY SPECIAL things that can be done to have
    two separate processes listen to the same socket (protocol / address /
    port) but it requires VERY SPECIAL provisions including both processes
    have to explicitly support it and I believe that the kernel has to
    support it. -- I can't think of an example where I've seen two
    different and unrelated processes listening on the same socket.

    N.B. that things like `sslh` don't violate this precept because sslh is
    the process listening on the socket and passing / proxying traffic to
    the other processes listening on different sockets.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From hongyi.zhao@gmail.com@21:1/5 to Kees Nuyt on Mon Mar 6 00:05:38 2023
    On Monday, March 6, 2023 at 2:01:36 AM UTC+8, Kees Nuyt wrote:
    On Sat, 4 Mar 2023 04:45:24 -0800 (PST), "hongy...@gmail.com" <hongy...@gmail.com> wrote:

    Now, add the -p option to see if udp and tcp are served by the
    same process:
    sudo ss -ltunp

    See the following:

    werner@X10DAi:~$ ss -ltunp | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=4))
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=3))
    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    3123709 3123347 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    3123715 3123709 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    Ok, there you are, that's clear. And what does the sslocal docs
    tell you?

    TBF, I don't know. This is a program that stopped developing many years ago, and its documentation is not friendly.

    --
    Kees Nuyt

    Zhao

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kees Nuyt@21:1/5 to hongyi.zhao@gmail.com on Mon Mar 6 17:14:39 2023
    On Mon, 6 Mar 2023 00:05:38 -0800 (PST), "hongy...@gmail.com" <hongyi.zhao@gmail.com> wrote:

    On Monday, March 6, 2023 at 2:01:36?AM UTC+8, Kees Nuyt wrote:
    On Sat, 4 Mar 2023 04:45:24 -0800 (PST), "hongy...@gmail.com"
    <hongy...@gmail.com> wrote:

    Now, add the -p option to see if udp and tcp are served by the
    same process:
    sudo ss -ltunp

    See the following:

    werner@X10DAi:~$ ss -ltunp | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=4))
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=3))
    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    3123709 3123347 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    3123715 3123709 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    Ok, there you are, that's clear. And what does the sslocal docs
    tell you?

    TBF, I don't know. This is a program that stopped developing
    many years ago, and its documentation is not friendly.

    It was brought to my attention that this subject is off-topic in comp.unix.shell , so I declare this END-OF-THREAD
    --
    Kees Nuyt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jalen Q@21:1/5 to Kees Nuyt on Sat Apr 1 19:53:03 2023
    On Monday, March 6, 2023 at 10:14:46 AM UTC-6, Kees Nuyt wrote:
    On Mon, 6 Mar 2023 00:05:38 -0800 (PST), "hongy...@gmail.com" <hongy...@gmail.com> wrote:
    On Monday, March 6, 2023 at 2:01:36?AM UTC+8, Kees Nuyt wrote:
    On Sat, 4 Mar 2023 04:45:24 -0800 (PST), "hongy...@gmail.com"
    <hongy...@gmail.com> wrote:

    Now, add the -p option to see if udp and tcp are served by the
    same process:
    sudo ss -ltunp

    See the following:

    werner@X10DAi:~$ ss -ltunp | grep '10014'
    udp UNCONN 0 0 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=4))
    tcp LISTEN 0 1024 0.0.0.0:10014 0.0.0.0:* users:(("sslocal",pid=3123715,fd=3))
    werner@X10DAi:~$ ps xao pid,ppid,pgid,sid,sgid,command | grep ' -l 10014' |grep -v grep
    3123709 3123347 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    3123715 3123709 3123347 3119533 1000 sslocal -c /home/werner/Public/anti-gfw/conf/ssr2json/ssr/US_ssr_eebzkdao.nodelist.xyz_1381_1421cc147ea4bb31049aea01851aac7e.json -l 10014
    Ok, there you are, that's clear. And what does the sslocal docs
    tell you?

    TBF, I don't know. This is a program that stopped developing
    many years ago, and its documentation is not friendly.
    It was brought to my attention that this subject is off-topic in comp.unix.shell , so I declare this END-OF-THREAD
    --
    Kees Nuyt
    fggggggtguttututttut8tttftytttffyy

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)