Re: when the sshd hits the fan

On Wed, Sep 23, 2015, at 10:35, Glenn English wrote: > Mildly OT from a profound BSD noob: > > Why is it necessary to have SSH working before the system has finished > booting? That 'Welcome' menu times out, so I can't think of a reason, or > find one from Goggle, for needing console access

Re: when the sshd hits the fan

Hi. On 23.09.2015 15:11, Miroslav Lachman wrote: > Eugene M. Zheganin wrote on 09/23/2015 10:44: >> Hi. >> >> I'm trying to understand why the sshd still starts after local daemons, >> out-of-the-box, and what it takes to make this extremely vital service >> to start before non-system (local)

Re: when the sshd hits the fan

Eugene M. Zheganin wrote on 09/23/2015 12:38: I was thinking about this a long time ago and instead of trying to change FreeBSD, But why ? I tried it before with some other changes (e-mails / PRs can be found) without much success so I gave up. I rather keep my changes local without

Re: when the sshd hits the fan

"Eugene M. Zheganin" writes: > I'm trying to understand why the sshd still starts after local daemons, > out-of-the-box, and what it takes to make this extremely vital service > to start before non-system (local) ones. I bet I'm not the first one to > ask, so why isn't this

Re: when the sshd hits the fan

On Sep 23 12:44, Kurt Jaeger wrote: It did enter the PR system. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190447 I'll have a look at it, it annoys me as well 8-} If this type of thing is being done on the base system sshd it would also be useful to look at the port version of ssh

Re: when the sshd hits the fan

Eugene M. Zheganin wrote on 09/23/2015 10:44: Hi. I'm trying to understand why the sshd still starts after local daemons, out-of-the-box, and what it takes to make this extremely vital service to start before non-system (local) ones. I bet I'm not the first one to ask, so why isn't this already

Re: when the sshd hits the fan

Hi! > > I'm trying to understand why the sshd still starts after local daemons, > > out-of-the-box, and what it takes to make this extremely vital service > > to start before non-system (local) ones. I bet I'm not the first one to > > ask, so why isn't this already done ? Seems quite easy for me.

Re: when the sshd hits the fan

On Wed, Sep 23, 2015 at 3:57 AM, Doug Hardie wrote: > >> On 23 September 2015, at 01:44, Eugene M. Zheganin >> wrote: >> >> Hi. >> >> I'm trying to understand why the sshd still starts after local daemons, >> out-of-the-box, and what it takes to make this

Re: when the sshd hits the fan

Hi. On 23.09.2015 18:32, Dag-Erling Smørgrav wrote: "Eugene M. Zheganin" writes: I'm trying to understand why the sshd still starts after local daemons, out-of-the-box, and what it takes to make this extremely vital service to start before non-system (local) ones. I bet

Re: when the sshd hits the fan

On Wed, Sep 23, 2015 at 01:37:30PM +0100, Matt Smith wrote: > If this type of thing is being done on the base system sshd it would > also be useful to look at the port version of ssh as well? I use the > port and it has always annoyed me that I get constant "connection > refused" whilst I'm

Re: when the sshd hits the fan

Mildly OT from a profound BSD noob: Why is it necessary to have SSH working before the system has finished booting? That 'Welcome' menu times out, so I can't think of a reason, or find one from Goggle, for needing console access after a power failure reboot. What am I unaware of? -- Glenn

Re: when the sshd hits the fan

On Wed, Sep 23, 2015 at 09:35:09AM -0600, Glenn English wrote: > Mildly OT from a profound BSD noob: > > Why is it necessary to have SSH working before the system has > finished booting? That 'Welcome' menu times out, so I can't think of > a reason, or find one from Goggle, for needing console

Re: when the sshd hits the fan

Sendmail for one can hang for stupidly long times waiting in dead resolvers before allowing the system to continue booting. That's the most common thing, RC scripts hanging waiting on external resources while you're locked out simply because sshd starts ridiculously late. Very common problem. On

Re: when the sshd hits the fan

Hi. On 23.09.2015 20:35, Glenn English wrote: Mildly OT from a profound BSD noob: Why is it necessary to have SSH working before the system has finished booting? That 'Welcome' menu times out, so I can't think of a reason, or find one from Goggle, for needing console access after a power

Re: when the sshd hits the fan

> On 23 September 2015, at 03:44, Kurt Jaeger wrote: > > Hi! > >>> I'm trying to understand why the sshd still starts after local daemons, >>> out-of-the-box, and what it takes to make this extremely vital service >>> to start before non-system (local) ones. I bet I'm not the

Re: when the sshd hits the fan

On Sep 23, 2015, at 10:00 AM, Michael Loftis wrote: > Sendmail for one can hang for stupidly long times waiting in dead resolvers > before allowing the system to continue booting. So replace it with Postfix? I've been using it (on Debian Linux) for decades without any

Re: when the sshd hits the fan

Glenn English writes: > On Sep 23, 2015, at 10:00 AM, Michael Loftis wrote: > >> That's the most common thing, RC scripts hanging waiting on external >> resources while you're locked out simply because sshd starts >> ridiculously late. Very common problem. >

when the sshd hits the fan

Hi. I'm trying to understand why the sshd still starts after local daemons, out-of-the-box, and what it takes to make this extremely vital service to start before non-system (local) ones. I bet I'm not the first one to ask, so why isn't this already done ? Seems quite easy for me. Eugene.

Re: when the sshd hits the fan

On Sep 23, 2015, at 1:13 PM, Lowell Gilbert wrote: > Yes; that's done with rcorder(8). The startup order isn't completely > defined, just the dependencies that require being started before (or, > occasionally, after) some other service. Well, that's all

Re: when the sshd hits the fan

> On 23 September 2015, at 01:44, Eugene M. Zheganin wrote: > > Hi. > > I'm trying to understand why the sshd still starts after local daemons, > out-of-the-box, and what it takes to make this extremely vital service > to start before non-system (local) ones. I bet I'm not