Pierre JEAN a écrit le 28.12.2008 17:49: > Followup-For: Bug #484861 > I can confirm this bug on current testing version (1:1.1.2-6lenny1), while > its ok for the stable release. > Is there any problem when passing outgoing port to sm-notify?
Here is what I could notice while trying and understanding this bug. Hope it could be helpful. sm-notify is run right after rpc.statd, leaving its pid in /var/run/sm-notify.pid (its pid is the rpc.statd one +1). sm-notify doesn't stay in background (running ps shows that the pid contained in sm-notify.pid has disappeared), so that I can't know with netstat or lsof if it holds a socket using the right port. netstat -ap shows rpc.statd holds a UDP socket on a random priviledged port (<1024) but this was controlled by the -o option on stable version (before separation of sm-notify from rpc.statd, rmtcall.c statd_get_socket() had a port parameter and was called with out_port, that is to say requested output port). So the question could be how to control this random port in order to make our NFS services compatible with paranoid firewall rules? Regards, Pierre_. # cat /var/run/sm-notify.pid 2036 # ps -el F S UID PID PPID C PRI NI ADDR SZ WCHAN TIME CMD [snip] 5 S 101 2035 1 0 80 0 - 826 - 00:00:00 rpc.statd 1 S 0 2101 2 0 75 -5 - 0 - 00:00:00 rpciod/0 [snap] # netstat -ap | grep stat tcp 0 0 *:rpc.statd *:* LISTEN 2035/rpc.statd udp 0 0 *:rpc.statd *:* 2035/rpc.statd udp 0 0 *:939 *:* 2035/rpc.statd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
