| 1 |
Apparently, though unproven, at 22:43 on Wednesday 08 June 2011, Grant Edwards |
| 2 |
did opine thusly: |
| 3 |
|
| 4 |
> On 2011-06-08, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 5 |
> > Apparently, though unproven, at 22:18 on Wednesday 08 June 2011, Grant |
| 6 |
> > Edwards |
| 7 |
> > |
| 8 |
> > did opine thusly: |
| 9 |
> >> A recent update seems to have broken sshd. It no longer starts when |
| 10 |
> >> it should. It seems to refuse to start up unless eth0 is up. For years |
| 11 |
> >> I've had the following in /etc/conf.d/rc |
| 12 |
> >> |
| 13 |
> >> RC_NET_STRICT_CHECKING="lo" |
| 14 |
> >> |
| 15 |
> >> According to the comments that means that the "net" service is up as |
| 16 |
> >> long as at least one interface (including lo) is up, and sshd used to |
| 17 |
> >> obey that setting. But now sshd seems to ignore that and has decided |
| 18 |
> >> that it knows better than I do -- it refuses to start when I tell it |
| 19 |
> >> to via "/etc/init.d/sshd start", and says "sshd is scheduled to start |
| 20 |
> >> when net.eth0 has started". I don't plan on starting net.eth0, but I |
| 21 |
> >> want sshd started anyway. If I'd meant "start if you happen to feel |
| 22 |
> >> like it" I would have typed |
| 23 |
> > |
| 24 |
> > Didn't read all the messages and files after upgrading openrc, right? |
| 25 |
> |
| 26 |
> I read them, but... |
| 27 |
> |
| 28 |
> > What you want is in /etc/rc.conf and it's now called rc_depend_strict |
| 29 |
> |
| 30 |
> Right: |
| 31 |
> |
| 32 |
> # Do we allow any started service in the runlevel to satisfy the |
| 33 |
> dependency # or do we want all of them regardless of state? For example, |
| 34 |
> if net.eth0 # and net.eth1 are in the default runlevel then with |
| 35 |
> rc_depend_strict="NO" # both will be started, but services that depend on |
| 36 |
> 'net' will work if either # one comes up. With rc_depend_strict="YES" we |
| 37 |
> would require them both to # come up. |
| 38 |
> #rc_depend_strict="YES" |
| 39 |
> |
| 40 |
> I had assumed that since the line setting it to YES was commented out |
| 41 |
> that the default was NO, and you uncommented the line to set it to |
| 42 |
> YES. I don't know where that belief came from, but it's wrong -- the |
| 43 |
> commented out line apparently shows the default. |
| 44 |
|
| 45 |
Yes, that stuff can get confusing and it's easy to get it mixed up. Te way |
| 46 |
it's done is the only really sane way - consider how it would play out if the |
| 47 |
setting was a value or a list of possibilities - you couldn't put a commented |
| 48 |
example in there that is the opposite of the default |
| 49 |
|
| 50 |
|
| 51 |
-- |
| 52 |
alan dot mckinnon at gmail dot com |
Archives