I agree this is an issue.  However, usually the PID is generated from the
startup script so that only the PID which is started by it is stopped.

Specifically, think of the use case of starting multiple SM's on different
ports.  For example a local user may do this to manage 2 subnets from one
node.  Your patch will, by default, overwrite the PID file with each instance.
(yes --pid-file can be specified but this is not very standard.)

I think a better (and more standard) approach is to do the following (untested):

diff --git a/scripts/opensm.init.in b/scripts/opensm.init.in
index 0c84bd3..1e053c4 100644
--- a/scripts/opensm.init.in
+++ b/scripts/opensm.init.in
@@ -42,6 +42,8 @@

 prefix=@prefix@
 exec_prefix=@exec_prefix@
+piddir=@localstatedir@
+PIDFILE=${piddir}/opensm.pid

 # Source function library.
 if [[ -s /etc/init.d/functions ]]; then
@@ -62,7 +64,7 @@ fi

 start () {
     echo -n "Starting opensm: "
-    @sbindir@/opensm --daemon $OPTIONS > /dev/null
+    daemon --pidfile=$PIDFILE @sbindir@/opensm --daemon $OPTIONS > /dev/null
     if [[ $RETVAL -eq 0 ]]; then
         touch /var/lock/subsys/opensm
         success
@@ -74,7 +76,7 @@ start () {

 stop () {
     echo -n "Shutting down opensm: "
-    killproc opensm
+    killproc -p $PIDFILE opensm
     if [[ $RETVAL -eq 0 ]]; then
         rm -f /var/lock/subsys/opensm
         success
@@ -85,7 +87,8 @@ stop () {
 }

 Xstatus () {
-       pid="`pidof opensm`"
+       pid=`cat $PIDFILE`
+       ps -p $pid
        ret=$?
        if [ $ret -eq 0 ] ; then
                echo "OpenSM is running... pid=$pid"
@@ -117,11 +120,11 @@ case "$1" in
        [ -e /var/lock/subsys/opensm ] && restart
        ;;
     resweep)
-       killall -HUP opensm
+       kill -s 1 `cat $PIDFILE`
         RETVAL=$?
        ;;
     rotatelog)
-       killall -USR1 opensm
+       kill -s 10 `cat $PIDFILE`
         RETVAL=$?
        ;;
     *)

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to