1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER.FRENCH

  • =?UTF-8?Q?Re=3A_Port_utilis=C3=A9_mais_PID/Program_name_vide?=

    From Jean-Marc@21:1/5 to All on Fri Jul 19 18:40:02 2024
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Gm3YqD0itI0CoMtR3rjtfU0m
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    TGUgMTkvMDcvMjQgw6AgMTY6MjksIE5vU3BhbSBhIMOpY3JpdMKgOg0KPiBCb25qb3VyDQoN CnNhbHV0LA0KDQo+IHN1ciB1bmUgZGViaWFuMTIgw6Agam91ciBqJ2FpDQo+IA0KPiBuZXRz dGF0IC02YXVwZW5sDQo+IA0KPiBQcm90byBSZWN2LVEgU2VuZC1RIEFkcmVzc2UgbG9jYWxl IEFkcmVzc2UgZGlzdC4gRXRhdCBVdGlsIElub2RlIFBJRC9Qcm8NCj4gdWRwNsKgwqDCoMKg wqDCoCAwwqDCoMKgwqDCoCAwIDo6OjUwMDA1wqDCoMKgwqDCoMKgIDo6OirCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDDCoMKgwqAgMzYzOTggLQ0KPiANCj4gbWFpcyBsc29mIC1p IC1QIC1uIHwgZ3JlcCA1MDAwNSBuJ2FmZmljaGUgYXVjdW5lIHNvcnRpZQ0KPiANCj4gQmll biDDqXZpZGVtbWVudCB1biBwcm9nciB1dGlsaXNlIGxlcyBwb3J0cyA1MDAwMDo1MDAxMCBl dCBuZSBzZSBsYW5jZSBwYXMNCj4gDQo+IENvbW1lbnQgc3VwcHJpbWVyIHVuZSB0w6JjaGUg cGFyIHNvbiBpbm9kZT8NCg0KRXNzYXllIHRvdWpvdXJzIGxhIGNvbW1hbmRlIHN1aXZhbnRl IDoNCg0Kc3VkbyBzcyAtdWxwIHNyYyA6NTAwMDUNCg0KQXZlYyB1biBwZXUgZGUgY2hhbmNl LCB0dSBhdXJhcyBsZSBwaWQgZHUgcHJvY2VzcyBxdWkgw6ljb3V0ZS4NCg0KPiBNZXJjaSBw b3VyIHRvdXRlIGlkw6llDQoNCi0tIA0KSmVhbi1NYXJjDQo=

    --------------Gm3YqD0itI0CoMtR3rjtfU0m--

    -----BEGIN PGP SIGNATURE-----

    iHUEARYIAB0WIQQe1tJ1wH7aHlIabXRcceD57QuFWAUCZpqU5AAKCRBcceD57QuF WNrbAP9SzbzW0RR5kekQNTk+ObxVkJeCUWtt3d0gUJ3f3oUUYwEAhQp2FxYRttM+ MXb3GU1pZY2pvTduvoERNZ4JLP6Howk=
    =uxNV
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoSpam@21:1/5 to All on Fri Jul 19 21:50:01 2024
    Le 19/07/2024 à 18:31, Jean-Marc a écrit :
    Le 19/07/24 à 16:29, NoSpam a écrit :
    Bonjour

    salut,

    sur une debian12 à jour j'ai

    netstat -6aupenl

    Proto Recv-Q Send-Q Adresse locale Adresse dist. Etat Util Inode PID/Pro
    udp6       0      0 :::50005       :::*               0    36398 -

    mais lsof -i -P -n | grep 50005 n'affiche aucune sortie

    Bien évidemment un progr utilise les ports 50000:50010 et ne se lance
    pas

    Comment supprimer une tâche par son inode?

    Essaye toujours la commande suivante :

    sudo ss -ulp src :50005
    State             Recv-Q            Send-Q Local Address:Port                          Peer Address:Port            Process
    UNCONN            0 0                                      [::]:50005
                                    [::]:*

    Avec un peu de chance, tu auras le pid du process qui écoute.

    Raté :( Cela dit netstat aurait également du l'afficher

    Merci pour l'idée

    --
    Daniel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles@21:1/5 to All on Mon Jul 22 00:30:01 2024
    Le 19/07/2024 à 16:29, NoSpam a écrit :
    Bonjour

    sur une debian12 à jour j'ai

    netstat -6aupenl

    Proto Recv-Q Send-Q Adresse locale Adresse dist. Etat Util Inode PID/Pro udp6       0      0 :::50005       :::*               0    36398 -

    mais lsof -i -P -n | grep 50005 n'affiche aucune sortie

    Bien évidemment un progr utilise les ports 50000:50010 et ne se lance pas

    Comment supprimer une tâche par son inode?

    Merci pour toute idée

    Bonsoir,

    Tu peux tenter en tant que root :

    # ls -l /proc/*/fd/* 2>/dev/null | grep 36398

    ça va ressortir les PID ayant une socket ouverte pour cet inode.

    Exemple (bien que là on sache déjà que c'est openvpn PID 684) :

    # netstat -6aupenl | grep openvpn
    udp6 0 0 :::1194 :::*
    0 12683 684/openvpn

    # ls -l /proc/*/fd/* 2>/dev/null | grep 12683
    lrwx------ 1 root root 64 21 juil. 23:53 /proc/684/fd/7 -> socket:[12683]

    # ps -wwf 684
    UID PID PPID C STIME TTY STAT TIME CMD
    nobody 684 1 0 juil.11 ? Ss 0:11 /usr/sbin/openvpn --daemon ovpn-server --status /run/openvpn/server.status 10 --cd
    /etc/openvpn --config /etc/openvpn/server.conf --writepid /run/openvpn/server.pid


    --
    Charles

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoSpam@21:1/5 to All on Mon Jul 22 09:50:02 2024
    Bonjour

    Le 22/07/2024 à 00:18, Charles a écrit :
    ls -l /proc/*/fd/* 2>/dev/null | grep 36398

    Pas plus efficace, aucune sortie.

    De mes tests, si netstat n'affiche aucun PID/nom de programme et que
    l'on ne sait pas par quel demon/application ce/ces ports sont ouverts,
    aucune chance de libérer le/les ports. C'est par ex. le cas avec des applications docker/proxy docker

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Charles@21:1/5 to All on Sat Jul 27 12:40:01 2024
    Le 22/07/2024 à 09:45, NoSpam a écrit :
    Bonjour

    Le 22/07/2024 à 00:18, Charles a écrit :
    ls -l /proc/*/fd/* 2>/dev/null | grep 36398

    Pas plus efficace, aucune sortie.

    De mes tests, si netstat n'affiche aucun PID/nom de programme et que
    l'on ne sait pas par quel demon/application ce/ces ports sont ouverts,
    aucune chance de libérer le/les ports. C'est par ex. le cas avec des applications docker/proxy docker


    C'est peut-être une communication via RPC, que donne la commande :
    # rpcinfo

    C'est le cas par exemple pour NFS, un netstat ne donnera aucun
    programme/PID associé car géré par le noyau.

    Tu peux tenter de chercher l'inode :

    # find / -inum 36398

    Peut-être tenter un nmap voir s'il te trouve un nom de service :

    # nmap -6 -v -A ::1 -p 50005

    Voire un tcpdump pour tenter d'identifier :

    # tcpdump -i any -vv -X udp port 50005

    Tu n'as pas de processus zombie ?

    Après un redémarrage le port est toujours en écoute ?

    --
    Charles

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoSpam@21:1/5 to All on Sat Jul 27 13:30:01 2024
    Le 27/07/2024 à 12:34, Charles a écrit :
    [...]
    Après un redémarrage le port est toujours en écoute ?

    Non et c'est ce qui m'a permis de libérer ce port mais d'autres sont
    dans le même cas après redémarrage.

    Merci pour tes idées, je continue à creuser car redémarrer n'est pas une solution.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoSpam@21:1/5 to All on Sat Jul 27 15:00:02 2024
    Le 27/07/2024 à 12:34, Charles a écrit :
    Le 22/07/2024 à 09:45, NoSpam a écrit :
    Bonjour

    Le 22/07/2024 à 00:18, Charles a écrit :
    ls -l /proc/*/fd/* 2>/dev/null | grep 36398

    Pas plus efficace, aucune sortie.

    De mes tests, si netstat n'affiche aucun PID/nom de programme et que
    l'on ne sait pas par quel demon/application ce/ces ports sont
    ouverts, aucune chance de libérer le/les ports. C'est par ex. le cas
    avec des applications docker/proxy docker


    C'est peut-être une communication via RPC, que donne la commande :
    # rpcinfo
    Aucun retour intéressant

    C'est le cas par exemple pour NFS, un netstat ne donnera aucun
    programme/PID associé car géré par le noyau.
    Exact

    Tu peux tenter de chercher l'inode :

    # find / -inum 36398
    Voir ci dessous

    Peut-être tenter un nmap voir s'il te trouve un nom de service :

    # nmap -6 -v -A ::1 -p 50005

    Cette cmd est très intéressante. Je cherche le port 2049 qui est NFS

    # nmap -4 -v -A 192.168.10.250 -p 2049

    PORT     STATE SERVICE VERSION
    2049/tcp open  nfs     3-4 (RPC #100003)

    netstat -tapen|grep 2049
    tcp        0      0 0.0.0.0:2049 0.0.0.0:*               LISTEN     
    0          34659 -
    tcp6       0      0 :::2049 :::*                    LISTEN     
    0          37193      -

    J'ai donc l'inode 34659, je tente

    # find / -inum 34659
    /usr/share/doc/usrmerge/README.Debian /sys/module/ip_tables/sections/.static_call_sites

    ????? La je en comprends pas.

    J'ai également un port 33921, inode 37199. Je recommence les tests

    # nmap -4 -v -A 192.168.10.250 -p 33921

    PORT      STATE SERVICE  VERSION
    33921/tcp open  nlockmgr 1-4 (RPC #100021)

    # find / -inum 37199
    /sys/module/acpi_power_meter/sections/.rodata

    Idem, quel est le lien entre le port et l'inode ? Bref ...

    [...]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoSpam@21:1/5 to All on Sat Jul 27 16:20:01 2024
    Le 27/07/2024 à 16:02, ajh-valmer a écrit :
    On Saturday 27 July 2024 12:34:15 Charles wrote:
    C'est peut-être une communication via RPC, que donne la commande :
    # rpcinfo :
    # apt-cache search rpcinfo
    ne donne rien...

    # apt-cache search rpcbind

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