Como dizer ao SMF que um serviço está realmente online?

Question

Isso parece trivial, mas eu tenho um serviço no Solaris 10 que está em execução, mas o SMF acha que não está.

Provavelmente consegui que o SMF tivesse o status correto parando e iniciando o serviço, mas, nesse caso, o serviço é SSH, o que significa que preciso estar no console do sistema para reiniciá-lo.

Como posso dizer ao SMF: "Este serviço está realmente funcionando; mova-o para o status 'on-line'?"

Editar : Algumas informações solicitadas sobre o serviço ssh:

A saída de /usr/lib/ssh/sshd -d | head -1 :

debug1: sshd version Sun_SSH_1.1

A saída de 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

A saída de 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

    

Answer 1

Se o seu serviço estiver no modo de manutenção, talvez seja necessário executar:

svcadm clear service

ou talvez:

svcadm refresh service

Se o serviço for reportado como offline, mas for realmente utilizável, você deve investigar mais para entender por que o smf pensa o contrário. Comece procurando os logs de serviço (veja a seguinte saída de comando para saber onde eles estão):

svcs -xv service

Edit: O problema é o principal sshd que está em execução (pid 453) não foi lançado pelo smf, mas pelo philadm, sem mencionar com um ambiente não suportado. Em qualquer caso, o smf não pode "adotar" este sshd. Você pode apenas matá-lo ( kill 453 ) e o smf deve poder iniciar o serviço ssh. Ambas as conexões ssh atuais não devem ser afetadas por este kill.