This seems trivial, but I have a service in Solaris 10 that's running but SMF thinks it isn't.
I could probably get SMF to have the right status by stopping and then starting the service, but in this case the service is SSH, which means I have to be at the system console to restart it.
How can I tell SMF, "This service is really running; please move it into 'online' status?"
Edit: Some information requested about the ssh service:
The output of /usr/lib/ssh/sshd -d | head -1
:
debug1: sshd version Sun_SSH_1.1
The output of ptree `pgrep sshd`
:
453 /usr/lib/ssh/sshd
11456 /usr/lib/ssh/sshd
11459 /usr/lib/ssh/sshd
11461 -tcsh
20521 /usr/lib/ssh/sshd
20524 /usr/lib/ssh/sshd
20526 -tcsh
22145 ptree 11459 20521 11456 20524 453
The output of pargs -e `pgrep sshd`
:
11459: /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun
20521: /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun
11456: /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun
20524: /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=philadm
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=bastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=steveadm
envp[23]: VENDOR=sun
453: /usr/lib/ssh/sshd
envp[0]: EDITOR=vi
envp[1]: GROUP=wheel
envp[2]: HOME=/home/philadm
envp[3]: HOST=radiance
envp[4]: HOSTTYPE=sun4
envp[5]: LANG=en_US.UTF-8
envp[6]: LD_LIBRARY_PATH=/opt/csw/lib/$ISALIST:/usr/local/lib:/usr/lib:/usr/dt/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
envp[7]: LOGNAME=philadm
envp[8]: MACHTYPE=sparc
envp[9]: MAIL=/var/mail//philadm
envp[10]: MANPATH=/opt/csw/share/man:/usr/local/man:/usr/man:/storage/lang/man:/usr/local/ssl/man
envp[11]: OSTYPE=solaris
envp[12]: PATH=/bin:/sbin:/usr/sbin:/opt/csw/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/bin/nsr:/usr/sbin/nsr:/opt/hpnpl/bin:/usr/openwin/bin:/usr/sbin:/usr/bin
envp[13]: PWD=/var/log
envp[14]: REMOTEHOST=cbastion2.example.com
envp[15]: SHELL=/bin/tcsh
envp[16]: SHLVL=1
envp[17]: SSH_CLIENT=192.168.1.45 45010 22
envp[18]: SSH_CONNECTION=192.168.1.45 45010 192.168.1.5 22
envp[19]: SSH_TTY=/dev/pts/2
envp[20]: TERM=xterm
envp[21]: TZ=US/Eastern
envp[22]: USER=philadm
envp[23]: VENDOR=sun
If your service is in maintenance mode, you might just need to run:
or perhaps:
If the service is reported as offline but is actually usable, you should investigate further to understand why smf thinks otherwise. Start by looking the service logs (look at the following command output to know where they are):
Edit: The issue is the main
sshd
which is running (pid 453) has not been launched by smf but by philadm, not to mention with an unsupported environment. In any case, smf cannot "adopt" this sshd. You might just kill it (kill 453
) and smf should be able to start the ssh service. Both current ssh connections shouldn't be affected by this kill.