Apparently, though unproven, at 22:43 on Wednesday 08 June 2011, Grant Edwards did opine thusly:
> On 2011-06-08, Alan McKinnon <alan.mckin...@gmail.com> wrote: > > Apparently, though unproven, at 22:18 on Wednesday 08 June 2011, Grant > > Edwards > > > > did opine thusly: > >> A recent update seems to have broken sshd. It no longer starts when > >> it should. It seems to refuse to start up unless eth0 is up. For years > >> I've had the following in /etc/conf.d/rc > >> > >> RC_NET_STRICT_CHECKING="lo" > >> > >> According to the comments that means that the "net" service is up as > >> long as at least one interface (including lo) is up, and sshd used to > >> obey that setting. But now sshd seems to ignore that and has decided > >> that it knows better than I do -- it refuses to start when I tell it > >> to via "/etc/init.d/sshd start", and says "sshd is scheduled to start > >> when net.eth0 has started". I don't plan on starting net.eth0, but I > >> want sshd started anyway. If I'd meant "start if you happen to feel > >> like it" I would have typed > > > > Didn't read all the messages and files after upgrading openrc, right? > > I read them, but... > > > What you want is in /etc/rc.conf and it's now called rc_depend_strict > > Right: > > # Do we allow any started service in the runlevel to satisfy the > dependency # or do we want all of them regardless of state? For example, > if net.eth0 # and net.eth1 are in the default runlevel then with > rc_depend_strict="NO" # both will be started, but services that depend on > 'net' will work if either # one comes up. With rc_depend_strict="YES" we > would require them both to # come up. > #rc_depend_strict="YES" > > I had assumed that since the line setting it to YES was commented out > that the default was NO, and you uncommented the line to set it to > YES. I don't know where that belief came from, but it's wrong -- the > commented out line apparently shows the default. Yes, that stuff can get confusing and it's easy to get it mixed up. Te way it's done is the only really sane way - consider how it would play out if the setting was a value or a list of possibilities - you couldn't put a commented example in there that is the opposite of the default -- alan dot mckinnon at gmail dot com
