One of our servers (tribble.east) running s10_67 gets stuck on every
boot with sshd being offline:
# svcs | grep offline
offline 9:34:32 svc:/network/ssh:default
#
There doesn't seem to be a reason for this, though. svcs -l remains
mum:
# svcs -l svc:/network/ssh:default
fmri svc:/network/ssh:default
enabled true
state offline
next_state none
restarter svc:/system/svc/restarter:default
dependency require_all/restart file://localhost/etc/ssh/sshd_config (-)
dependency require_all/none svc:/system/cryptosvc (online)
dependency require_all/none svc:/network/loopback (online)
dependency require_all/none svc:/system/filesystem/usr:default (online)
# pgrep ssh
#
Everything needed is online, but the service itself is not. There
aren't any syslog messages:
# grep ssh /var/adm/messages
#
and the /var/svc/log/network-ssh:default.log file is empty.
At a guess (and only a guess), there's something amiss with the way
dependencies are computed, so I have a core dump of svc.startd here:
/net/tribble.east/export/build/core/core.7
One more data point: doing the following fixes the problem. It
shouldn't do anything, but it works.
# svcadm disable svc:/network/ssh:default
# svcadm enable svc:/network/ssh:default
The comments cover these points, but to be clear, I believe the
following issues must be addressed with this bug:
1) svcs (-x, -l, -d) must be more illuminating for file: dependencies.
If the admin can't figure out that it is the file: dependency keeping
their service offline, we've still got a problem. (Partially covered by
6249160.)
2) file: dependencies should be re-evaluated on service restart, not
just on disable/enable. If "svcadm restart" behaves any differently
than "svcadm disable; svcadm enable" when a file: dependency is
offline (or for any other reason), it must be fixed. (Covered by
6227518.)
3) The lack of re-check of file: dependencies renders them mostly
useless. We need to either improve or deprecate them and introduce
a better model. (For now, documentation won't recommend using them,
and we're removing them from many internal services. See 6240573.)
Work Around
Usually, create the file that's required by the service then
svcadm disable; svcadm enable the service. This is ugly, since disable/enable
shouldn't behave differently than svcadm restart, but that's why this is a bug.
If the problem only happens during boot, check to see if the config file is
located on a remote filesystem. If so, make sure there's an appropriate
dependency (e.g. on autofs) to make sure the filesystem is mounted when the
service starts.