Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
    
You should be able to issue a restart without interrupting your session as it just stops "new" clients from connecting. That's with *nix though ...Solaris is a different beast. –  Nathan C May 22 '13 at 14:59
    
On Solaris (and with Sun SSH, which is a lightly-modified fork of OpenSSH), a restart of the service just sends a signal to the sshd process. I'm not brave enough to try stopping the service remotely, just in case it does kill my session. (Also, I'd like to know if there's a correct answer to this, as the next time I might not be able to shut down the service without customers noticing.) –  asciiphil May 22 '13 at 17:36
    
@NathanC Solaris is definitely *nix, Unix even ... –  jlliagre May 28 '13 at 21:04

1 Answer 1

up vote 2 down vote accepted

If your service is in maintenance mode, you might just need to run:

svcadm clear service

or perhaps:

svcadm refresh service

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):

svcs -xv service

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.

share|improve this answer
    
svcs reports that the service is offline, even though sshd is running and accepting connections. I don't know how it got into this state. When I run svcadm start sshd, it calls sshd, which exits immediately (because another instance is already running), so SMF still thinks the service is offline. –  asciiphil May 26 '13 at 16:47
    
Have you installed an alternate sshd package on that machine ? Please update you questions with the output of these ksh/bash commands as root: ptree $(pgrep sshd) and pargs -e $(pgrep sshd) –  jlliagre May 26 '13 at 22:01
    
Question updated. –  asciiphil May 28 '13 at 13:13
    
Answer updated ! –  jlliagre May 28 '13 at 16:18
    
After killing the master process, SMF restarted sshd. You also answered the thing I really wanted to know about this with, "In any case, smf cannot 'adopt' this sshd." –  asciiphil May 28 '13 at 20:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.