If I install sshd (using the SMF manifest) option and want to run it on a different port (say for some chroot/sftp action) I end up generating pid-file collisions between the existing SMF_managed Solaris-SSHd. making the following change in: /lib/svc/method/site/opensshd PIDFILE=$piddir/opensshd.pid does NOT appear to solve the problem. (that PIDFILE variable seems to be entirely ignored) -- doing the following in the config-file DOES solve the pid-issue... /opt/OpenSSH//etc/sshd_config PidFile /var/run/opensshd.pid
Tim, you know more about SMF that I do - could you please take a look at this?
Created attachment 1726 [details] Use PidFile if set in sshd_config This is not really a SMF issue. The problem is our start/stop script does not know if PidFile is set in sshd_config. The attached patch would be one way to address this issue.
Comment on attachment 1726 [details] Use PidFile if set in sshd_config >--- openssh/opensshd.init.in.old 2006-01-31 08:00:37.000000000 -0800 >+++ openssh/opensshd.init.in 2009-11-19 21:27:44.657360000 -0800 >@@ -14,6 +14,8 @@ > > SSHD=$prefix/sbin/sshd > PIDFILE=$piddir/sshd.pid >+PidFile=`grep "^PidFile " ${sysconfdir}/sshd_config | awk '{print $2}'` I don't think this will cope '=' as a config separator, which is legal sshd_config syntax: PidFile=/somewhere/sshd.pid
Created attachment 1730 [details] take 2 (In reply to comment #3) > (From update of attachment 1726 [details]) > >+PidFile=`grep "^PidFile " ${sysconfdir}/sshd_config | awk '{print $2}'` > > I don't think this will cope '=' as a config separator, which is legal > sshd_config syntax: > > PidFile=/somewhere/sshd.pid Good point. This one will.
Created attachment 1731 [details] take 3 Oh rats. take2 handled all cases except the one djm mentioned. OK, this one really works.
Comment on attachment 1731 [details] take 3 looks good, do it!
(In reply to comment #6) > (From update of attachment 1731 [details]) > looks good, do it! OK, I've commited the patch. It should show up in a snapshot shortly and will be in 5.4. Marking this bug resolved.
With the release of 5.4p1, this bug is now considered closed.