rsync i rpc.statd

[Andrzej Krzysztofowicz]

Tomasz Wittner wrote:
> A co zajmowania portu udp/871 (po restarcie 618) - akurat nie koliduje z rsync - ok - ale
> może potencjalnie z czymś innym, co ma z góry zdefiniowany port, na którym ma działać,
> a startuje po nfslock. Nie wiem, na jakiej zasadzie podzepia się pod różne porty i co w takim
> razie daje opcja --port , skoro oprócz portu 1001 zajmuje 1 inny z "niewiadomojakiego" zakresu.
> udp        0      0 0.0.0.0:1001            0.0.0.0:*                           28850/rpc.statd
> udp        0      0 0.0.0.0:618             0.0.0.0:*                           28850/rpc.statd

[root w kufel root]# netstat -apn | grep statd
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:937             0.0.0.0:*               LISTEN
24075/rpc.statd
udp        0      0 0.0.0.0:931             0.0.0.0:*
24075/rpc.statd
udp        0      0 0.0.0.0:934             0.0.0.0:*
24075/rpc.statd
[root w kufel root]# rpcinfo -p | grep stat
    100024    1   udp    934  status
    100024    1   tcp    937  status

Rzeczywiscie otwiera dwa porty UDP, z czego jeden zawsze dynamicznie
alokowany. Brzydko. Ale nie mam pojecia do czego on moze sluzyc.
Chyba bez grzebniecia po zrodlach sie nie obejdzie...

Tyle, ze w przypadku UDP ryzyko kolizji jest duzo mniejsze. CHyba malo co
korzysta ze statycznej alokacji portow UDP w tym zakresie.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology