On Fri, 17 Sep 2010, Chuck Lever wrote: > On Sep 17, 2010, at 3:04 PM, Jan Rękorajski wrote: > > > On Fri, 17 Sep 2010, Chuck Lever wrote: > > > >> > >> On Sep 17, 2010, at 2:12 PM, Jan Rękorajski wrote: > >> > >>> Hi, > >>> rpcbind currently silently ignores any errors that occur during > >>> init_transport, it also happily continues if bind(2) fails for > >>> UDP socket - it's enough if just one UDP socket is bound. > >>> > >>> This patch makes rpcbind fail if there are problems with > >>> setting up any transport, so we don't end up with > >>> semi/non functional running daemon. > >> > >> Can you give us some details about why transport initialization was > >> failing? There are probably some cases where we do want rpcbind to > >> soldier on in spite of such troubles. > > > > An obvious example is when address given to '-h' option isn't there, > > or daemon can't bind to it for some reason. > > Bind fails, but rpcbind is running as if nothing happened. > > The usual practice is to allow an RPC daemon to run if at least one > transport can be started. That is a little more robust than failing > if any one transport can't be started. > > If such a failure is completely silent, then it's probably reasonable > to post a notice about this in the log. But we generally like things > to work automatically, if at all possible. It does syslog all problems with creating sockets. > If rpcbind couldn't use _any_ of the specified bind addresses, I guess > that is when it should fail to start. A host's networking > configuration can be quite variable, especially with DHCP-configured > interfaces, so these daemons have to be somewhat flexible. Ok, I can live with that, it just seemed bad to me that those errors got ignored. > > And, besides, behavior for UDP and TCP sockets is currently inconsistent > > as init_transport ignores any failed UDP bind and correctly > > returns error for TCP. > > That _may_ be intentional. UDP semantics are "unreliable," so an > error may be expected even at bind time. Who knows, it doesn't look > very well documented. What about TCP then? My patch was a by-product of trying to make '-h <IP>' also work for tcp sockets, so if we skip unbindable addresses for UDP, then will it be ok to do the same for TCP? -- Jan Rękorajski | ALL SUSPECTS ARE GUILTY. PERIOD! baggins<at>mimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
