bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d]

[Glen Barber]

The following reply was made to PR bin/134694; it has been noted by GNATS.

From: Glen Barber <glen.j.barber at gmail.com>
To: Dimitry Andric <dimitry at andric.com>
Cc: hackers at freebsd.org, bug-followup at freebsd.org
Subject: Re: bin/134694: gives false-positive when unable to obtain socket 
	[WAS: sshd(8) - alert user when fails to execute from rc.d]
Date: Wed, 20 May 2009 13:39:28 -0400

 Hi, Dimitry
 
 On Wed, May 20, 2009 at 10:46 AM, Dimitry Andric <dimitry at andric.com> wrote=
 :
 > On 2009-05-20 16:40, Glen Barber wrote:
 >> sshd was listening on :25, both IPv4 and IPv6
 >> sendmail was listening on :25 (because I had forgotten to disable it)
 >>
 >> The system boots, and sendmail starts before sshd. =A0When sshd starts
 >> (or tries to) there is no console output that it had failed. =A0The only
 >> way you realize it is not running, is when you cannot remotely log in.
 >
 > Yes, this is unfortunate, but normal, as I explained in an earlier post.
 >
 > The sshd process does not return any error (and thus the /etc/rc.d
 > script doesn't either), because it has no way to know that its forked
 > copy died.
 >
 > The solution to this PR is "don't run stuff on conflicting ports". :)
 >
 
 I absolutely agree about not running sshd on conflicting ports.  After
 a bit more testing, I found that "most" other services will complain
 when they cannot obtain the requested socket, and you will see a
 failure notice via the rc.d script.
 
 My concern is when someone has a "definite need" to run sshd on a
 non-standard port less than, say 1024 for example.  This is the real
 reason I initially created the PR and posted to hackers@ about this --
 I'd like to fix it.  But, I want to fix it the right way, and not hack
 a crude solution.
 
 Regards,
 
 --=20
 Glen Barber