Thread: [Wrapper-user] Can't make old wrapper daemon go away

Brought to you by: maxime-tsl, mortenson, samanta-yoshida

wrapper-user

[Wrapper-user] Can't make old wrapper daemon go away

From: Mark L. <mid...@ve...> - 2007-03-05 06:18:47

I made some changes to my wrapper application on Mac OSX, and I can't 
make the old version go away. Perhaps this happened because I checked 
"Open at login" in the dock. I run the new version of the app and it 
can't run because the old version is running and has the IP port locked 
up. So I find a java process with parent process = wrapper, and I kill 
it, and it comes right back. I've looked in all the LaunchDaemons 
folders and StartupItems folders, and I can't find what's making this 
old version of the app start up over and over. When I execute "myAppName 
status" I see that it's not running. But the old version is still 
running, and I don't know how to kill it permanently.

-Mark

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Mark L. <mid...@ve...> - 2007-03-05 14:12:16

Mark Leone wrote:
> I made some changes to my wrapper application on Mac OSX, and I can't 
> make the old version go away. Perhaps this happened because I checked 
> "Open at login" in the dock. I run the new version of the app and it 
> can't run because the old version is running and has the IP port locked 
> up. So I find a java process with parent process = wrapper, and I kill 
> it, and it comes right back. I've looked in all the LaunchDaemons 
> folders and StartupItems folders, and I can't find what's making this 
> old version of the app start up over and over. When I execute "myAppName 
> status" I see that it's not running. But the old version is still 
> running, and I don't know how to kill it permanently.
>
> -Mark
>
>   
This seems to be another manifestation of the problem I reported in an 
earlier thread, which was fixed by the new script found at

http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in.

But I just re-loaded that script again to make sure I didn't somehow 
revert to the old one, and I still have the same problem. I'm having 
this problem with two separate applications that I'm running via wrapper 
on OSX. My executables renamed from script.sh.in are RCBServer and 
RCBClient. For example, I type "./RCBServer start" and I get what looks 
like a normal startup. Then I type "./RCBServer status" and I get

Removed stale pid file: /Applications/Remote 
Clipboard/RCBServer/bin/./RCBServer.pid
RCBServer is not running.
Mac-mini:/Applications/Remote Clipboard/RCBServer/bin Martha$

And I can't stop the daemon now because wrapper thinks it's not running. 
The only way I can stop it is to kill the process named wrapper.

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Mark L. <mid...@ve...> - 2007-03-07 13:55:21

Mark Leone wrote:
> Mark Leone wrote:
>> I made some changes to my wrapper application on Mac OSX, and I can't 
>> make the old version go away. Perhaps this happened because I checked 
>> "Open at login" in the dock. I run the new version of the app and it 
>> can't run because the old version is running and has the IP port 
>> locked up. So I find a java process with parent process = wrapper, 
>> and I kill it, and it comes right back. I've looked in all the 
>> LaunchDaemons folders and StartupItems folders, and I can't find 
>> what's making this old version of the app start up over and over. 
>> When I execute "myAppName status" I see that it's not running. But 
>> the old version is still running, and I don't know how to kill it 
>> permanently.
>>
>> -Mark
>>
>>   
> This seems to be another manifestation of the problem I reported in an 
> earlier thread, which was fixed by the new script found at
>
> http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in. 
>
>
> But I just re-loaded that script again to make sure I didn't somehow 
> revert to the old one, and I still have the same problem. I'm having 
> this problem with two separate applications that I'm running via 
> wrapper on OSX. My executables renamed from script.sh.in are RCBServer 
> and RCBClient. For example, I type "./RCBServer start" and I get what 
> looks like a normal startup. Then I type "./RCBServer status" and I get
>
> Removed stale pid file: /Applications/Remote 
> Clipboard/RCBServer/bin/./RCBServer.pid
> RCBServer is not running.
> Mac-mini:/Applications/Remote Clipboard/RCBServer/bin Martha$
>
> And I can't stop the daemon now because wrapper thinks it's not 
> running. The only way I can stop it is to kill the process named wrapper.
>
Am I the only one who's seeing this regression? It was working fine, but 
suddenly on OSX I get the problem that existed before and was fixed by 
the new shell script that Leif provided. I've tried everything and I 
can't make it work properly as it did before. It writes the pid for the 
wrapper process to the pid file, and then reports a stale pid when I try 
to get status or stop the service.

-Mark

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Leif M. <le...@ta...> - 2007-03-09 04:05:59

Mark,
    The list is working fine.  I will cc you directly in case you aren't 
getting messages from
the list for some reason.
    Let me recap.  You were experiencing a problem stopping the Wrapper 
on OSX.
We resolved that this was a bug in the 3.2.3 shell script.  I made a 
script with a fix
available to you and it started working.
    Now you are having the original problem again.

    The first question I have is are you "sure" that you are not using 
the original broken
script?  And if so why?   How are you running the script?

Cheers,
Leif

Mark Leone wrote:
> Mark Leone wrote:
>   
>> Mark Leone wrote:
>>     
>>> I made some changes to my wrapper application on Mac OSX, and I can't 
>>> make the old version go away. Perhaps this happened because I checked 
>>> "Open at login" in the dock. I run the new version of the app and it 
>>> can't run because the old version is running and has the IP port 
>>> locked up. So I find a java process with parent process = wrapper, 
>>> and I kill it, and it comes right back. I've looked in all the 
>>> LaunchDaemons folders and StartupItems folders, and I can't find 
>>> what's making this old version of the app start up over and over. 
>>> When I execute "myAppName status" I see that it's not running. But 
>>> the old version is still running, and I don't know how to kill it 
>>> permanently.
>>>
>>> -Mark
>>>
>>>   
>>>       
>> This seems to be another manifestation of the problem I reported in an 
>> earlier thread, which was fixed by the new script found at
>>
>> http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in. 
>>
>>
>> But I just re-loaded that script again to make sure I didn't somehow 
>> revert to the old one, and I still have the same problem. I'm having 
>> this problem with two separate applications that I'm running via 
>> wrapper on OSX. My executables renamed from script.sh.in are RCBServer 
>> and RCBClient. For example, I type "./RCBServer start" and I get what 
>> looks like a normal startup. Then I type "./RCBServer status" and I get
>>
>> Removed stale pid file: /Applications/Remote 
>> Clipboard/RCBServer/bin/./RCBServer.pid
>> RCBServer is not running.
>> Mac-mini:/Applications/Remote Clipboard/RCBServer/bin Martha$
>>
>> And I can't stop the daemon now because wrapper thinks it's not 
>> running. The only way I can stop it is to kill the process named wrapper.
>>
>>     
> Am I the only one who's seeing this regression? It was working fine, but 
> suddenly on OSX I get the problem that existed before and was fixed by 
> the new shell script that Leif provided. I've tried everything and I 
> can't make it work properly as it did before. It writes the pid for the 
> wrapper process to the pid file, and then reports a stale pid when I try 
> to get status or stop the service.
>
> -Mark
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Mark L. <mid...@ve...> - 2007-03-09 04:51:27

Attachments: wrapper.conf

#! /bin/sh

#
# Copyright (c) 1999, 2007 Tanuki Software Inc.
#
# Java Service Wrapper sh script.  Suitable for starting and stopping
#  wrapped Java applications on UNIX platforms.
#

#-----------------------------------------------------------------------------
# These settings can be modified to fit the needs of your application

# Application
APP_NAME="RCBServer"
APP_LONG_NAME="Remote_Clipboard_Server"

# Wrapper
WRAPPER_CMD="./wrapper"
WRAPPER_CONF="../conf/wrapper.conf"

# Priority at which to run the wrapper.  See "man nice" for valid priorities.
#  nice is only used if a priority is specified.
PRIORITY=

# Location of the pid file.
PIDDIR="."

# If uncommented, causes the Wrapper to be shutdown using an anchor file.
#  When launched with the 'start' command, it will also ignore all INT and
#  TERM signals.
#IGNORE_SIGNALS=true

# Wrapper will start the JVM asynchronously. Your application may have some
#  initialization tasks and it may be desirable to wait a few seconds
#  before returning.  For example, to delay the invocation of following
#  startup scripts.  Setting WAIT_AFTER_STARTUP to a positive number will
#  cause the start command to delay for the indicated period of time 
#  (in seconds).
# 
WAIT_AFTER_STARTUP=0

# If specified, the Wrapper will be run as the specified user.
# IMPORTANT - Make sure that the user has the required privileges to write
#  the PID file and wrapper.log files.  Failure to be able to write the log
#  file will cause the Wrapper to exit without any way to write out an error
#  message.
# NOTE - This will set the user which is used to run the Wrapper as well as
#  the JVM and is not useful in situations where a privileged resource or
#  port needs to be allocated prior to the user being changed.
#RUN_AS_USER=

# The following two lines are used by the chkconfig command. Change as is
#  appropriate for your application.  They should remain commented.
# chkconfig: 2345 20 80
# description: @app.long.name@

# Do not modify anything beyond this point
#-----------------------------------------------------------------------------

# Get the fully qualified path to the script
case $0 in
    /*)
        SCRIPT="$0"
        ;;
    *)
        PWD=`pwd`
        SCRIPT="$PWD/$0"
        ;;
esac

# Resolve the true real path without any sym links.
CHANGED=true
while [ "X$CHANGED" != "X" ]
do
    # Change spaces to ":" so the tokens can be parsed.
    SAFESCRIPT=`echo $SCRIPT | sed -e 's; ;:;g'`
    # Get the real path to this script, resolving any symbolic links
    TOKENS=`echo $SAFESCRIPT | sed -e 's;/; ;g'`
    REALPATH=
    for C in $TOKENS; do
        # Change any ":" in the token back to a space.
        C=`echo $C | sed -e 's;:; ;g'`
        REALPATH="$REALPATH/$C"
        # If REALPATH is a sym link, resolve it.  Loop for nested links.
        while [ -h "$REALPATH" ] ; do
            LS="`ls -ld "$REALPATH"`"
            LINK="`expr "$LS" : '.*-> \(.*\)$'`"
            if expr "$LINK" : '/.*' > /dev/null; then
                # LINK is absolute.
                REALPATH="$LINK"
            else
                # LINK is relative.
                REALPATH="`dirname "$REALPATH"`""/$LINK"
            fi
        done
    done

    if [ "$REALPATH" = "$SCRIPT" ]
    then
        CHANGED=""
    else
        SCRIPT="$REALPATH"
    fi
done

# Change the current directory to the location of the script
cd "`dirname "$REALPATH"`"
REALDIR=`pwd`

# If the PIDDIR is relative, set its value relative to the full REALPATH to avoid problems if
#  the working directory is later changed.
FIRST_CHAR=`echo $PIDDIR | cut -c1,1`
if [ "$FIRST_CHAR" != "/" ]
then
    PIDDIR=$REALDIR/$PIDDIR
fi
# Same test for WRAPPER_CMD
FIRST_CHAR=`echo $WRAPPER_CMD | cut -c1,1`
if [ "$FIRST_CHAR" != "/" ]
then
    WRAPPER_CMD=$REALDIR/$WRAPPER_CMD
fi
# Same test for WRAPPER_CONF
FIRST_CHAR=`echo $WRAPPER_CONF | cut -c1,1`
if [ "$FIRST_CHAR" != "/" ]
then
    WRAPPER_CONF=$REALDIR/$WRAPPER_CONF
fi

# Process ID
ANCHORFILE="$PIDDIR/$APP_NAME.anchor"
PIDFILE="$PIDDIR/$APP_NAME.pid"
LOCKDIR="/var/lock/subsys"
LOCKFILE="$LOCKDIR/$APP_NAME"
pid=""

# Resolve the location of the 'ps' command
PSEXE="/usr/bin/ps"
if [ ! -x "$PSEXE" ]
then
    PSEXE="/bin/ps"
    if [ ! -x "$PSEXE" ]
    then
        echo "Unable to locate 'ps'."
        echo "Please report this message along with the location of the command on your system."
        exit 1
    fi
fi

# Resolve the os
DIST_OS=`uname -s | tr [:upper:] [:lower:] | tr -d [:blank:]`
case "$DIST_OS" in
    'sunos')
        DIST_OS="solaris"
        ;;
    'hp-ux' | 'hp-ux64')
        # HP-UX needs the XPG4 version of ps (for -o args)
        DIST_OS="hpux"
        UNIX95=""
        export UNIX95   
        ;;
    'darwin')
        DIST_OS="macosx"
        ;;
    'unix_sv')
        DIST_OS="unixware"
        ;;
esac

# Resolve the architecture
DIST_ARCH=`uname -p 2>/dev/null | tr [:upper:] [:lower:] | tr -d [:blank:]`
if [ $? -ne 0 ]
then
    DIST_ARCH="unknown"
fi
if [ "$DIST_ARCH" = "unknown" ]
then
    DIST_ARCH=`uname -m 2>/dev/null | tr [:upper:] [:lower:] | tr -d [:blank:]`
fi
case "$DIST_ARCH" in
    'amd64' | 'athlon' | 'ia32' | 'ia64' | 'i386' | 'i486' | 'i586' | 'i686' | 'x86_64')
        DIST_ARCH="x86"
        ;;
    'ip27')
        DIST_ARCH="mips"
        ;;
    'power' | 'powerpc' | 'power_pc' | 'ppc64')
        DIST_ARCH="ppc"
        ;;
    'pa_risc' | 'pa-risc')
        DIST_ARCH="parisc"
        ;;
    'sun4u' | 'sparcv9')
        DIST_ARCH="sparc"
        ;;
    '9000/800')
        DIST_ARCH="parisc"
        ;;
esac

outputFile() {
    if [ -f "$1" ]
    then
        echo "  $1 (Found but not executable.)";
    else
        echo "  $1"
    fi
}

# Decide on the wrapper binary to use.
# If a 32-bit wrapper binary exists then it will work on 32 or 64 bit
#  platforms, if the 64-bit binary exists then the distribution most
#  likely wants to use long names.  Otherwise, look for the default.
# For macosx, we also want to look for universal binaries.
WRAPPER_TEST_CMD="$WRAPPER_CMD-$DIST_OS-$DIST_ARCH-32"
if [ -x "$WRAPPER_TEST_CMD" ]
then
    WRAPPER_CMD="$WRAPPER_TEST_CMD"
else
    if [ "$DIST_OS" = "macosx" ]
    then
        WRAPPER_TEST_CMD="$WRAPPER_CMD-$DIST_OS-universal-32"
        if [ -x "$WRAPPER_TEST_CMD" ]
        then
            WRAPPER_CMD="$WRAPPER_TEST_CMD"
        else
            WRAPPER_TEST_CMD="$WRAPPER_CMD-$DIST_OS-$DIST_ARCH-64"
            if [ -x "$WRAPPER_TEST_CMD" ]
            then
                WRAPPER_CMD="$WRAPPER_TEST_CMD"
            else
                WRAPPER_TEST_CMD="$WRAPPER_CMD-$DIST_OS-universal-64"
                if [ -x "$WRAPPER_TEST_CMD" ]
                then
                    WRAPPER_CMD="$WRAPPER_TEST_CMD"
                else
                    if [ ! -x "$WRAPPER_CMD" ]
                    then
                        echo "Unable to locate any of the following binaries:"
                        outputFile "$WRAPPER_CMD-$DIST_OS-$DIST_ARCH-32"
                        outputFile "$WRAPPER_CMD-$DIST_OS-universal-32"
                        outputFile "$WRAPPER_CMD-$DIST_OS-$DIST_ARCH-64"
                        outputFile "$WRAPPER_CMD-$DIST_OS-universal-64"
                        outputFile "$WRAPPER_CMD"
                        exit 1
                    fi
                fi
            fi
        fi
    else
        WRAPPER_TEST_CMD="$WRAPPER_CMD-$DIST_OS-$DIST_ARCH-64"
        if [ -x "$WRAPPER_TEST_CMD" ]
        then
            WRAPPER_CMD="$WRAPPER_TEST_CMD"
        else
            if [ ! -x "$WRAPPER_CMD" ]
            then
                echo "Unable to locate any of the following binaries:"
                outputFile "$WRAPPER_CMD-$DIST_OS-$DIST_ARCH-32"
                outputFile "$WRAPPER_CMD-$DIST_OS-$DIST_ARCH-64"
                outputFile "$WRAPPER_CMD"
                exit 1
            fi
        fi
    fi
fi

# Build the nice clause
if [ "X$PRIORITY" = "X" ]
then
    CMDNICE=""
else
    CMDNICE="nice -$PRIORITY"
fi

# Build the anchor file clause.
if [ "X$IGNORE_SIGNALS" = "X" ]
then
   ANCHORPROP=
   IGNOREPROP=
else
   ANCHORPROP=wrapper.anchorfile=\"$ANCHORFILE\"
   IGNOREPROP=wrapper.ignore_signals=TRUE
fi

# Build the lock file clause.  Only create a lock file if the lock directory exists on this platform.
LOCKPROP=
if [ -d $LOCKDIR ]
then
    if [ -w $LOCKDIR ]
    then
        LOCKPROP=wrapper.lockfile=\"$LOCKFILE\"
    fi
fi

checkUser() {
    # $1 touchLock flag
    # $2 command

    # Check the configured user.  If necessary rerun this script as the desired user.
    if [ "X$RUN_AS_USER" != "X" ]
    then
        # Resolve the location of the 'id' command
        IDEXE="/usr/xpg4/bin/id"
        if [ ! -x "$IDEXE" ]
        then
            IDEXE="/usr/bin/id"
            if [ ! -x "$IDEXE" ]
            then
                echo "Unable to locate 'id'."
                echo "Please report this message along with the location of the command on your system."
                exit 1
            fi
        fi
    
        if [ "`$IDEXE -u -n`" = "$RUN_AS_USER" ]
        then
            # Already running as the configured user.  Avoid password prompts by not calling su.
            RUN_AS_USER=""
        fi
    fi
    if [ "X$RUN_AS_USER" != "X" ]
    then
        # If LOCKPROP and $RUN_AS_USER are defined then the new user will most likely not be
        # able to create the lock file.  The Wrapper will be able to update this file once it
        # is created but will not be able to delete it on shutdown.  If $2 is defined then
        # the lock file should be created for the current command
        if [ "X$LOCKPROP" != "X" ]
        then
            if [ "X$1" != "X" ]
            then
                # Resolve the primary group 
                RUN_AS_GROUP=`groups $RUN_AS_USER | awk '{print $3}' | tail -1`
                if [ "X$RUN_AS_GROUP" = "X" ]
                then
                    RUN_AS_GROUP=$RUN_AS_USER
                fi
                touch $LOCKFILE
                chown $RUN_AS_USER:$RUN_AS_GROUP $LOCKFILE
            fi
        fi

        # Still want to change users, recurse.  This means that the user will only be
        #  prompted for a password once. Variables shifted by 1
        # 
        # Use "runuser" if this exists.  runuser should be used on RedHat in preference to su.
        #
        if test -f "/sbin/runuser"
        then
            /sbin/runuser - $RUN_AS_USER -c "\"$REALPATH\" $2"
        else
            su - $RUN_AS_USER -c "\"$REALPATH\" $2"
        fi

        # Now that we are the original user again, we may need to clean up the lock file.
        if [ "X$LOCKPROP" != "X" ]
        then
            getpid
            if [ "X$pid" = "X" ]
            then
                # Wrapper is not running so make sure the lock file is deleted.
                if [ -f "$LOCKFILE" ]
                then
                    rm "$LOCKFILE"
                fi
            fi
        fi

        exit 0
    fi
}

getpid() {
    pid=""
    if [ -f "$PIDFILE" ]
    then
        if [ -r "$PIDFILE" ]
        then
            pid=`cat "$PIDFILE"`
            if [ "X$pid" != "X" ]
            then
                # It is possible that 'a' process with the pid exists but that it is not the
                #  correct process.  This can happen in a number of cases, but the most
                #  common is during system startup after an unclean shutdown.
                # The ps statement below looks for the specific wrapper command running as
                #  the pid.  If it is not found then the pid file is considered to be stale.
                case "$DIST_OS" in
                    'macosx')
                        pidtest=`$PSEXE -p $pid | grep "$WRAPPER_CMD" | tail -1`
                        ;;
                    *)
                        pidtest=`$PSEXE -p $pid -o args | grep "$WRAPPER_CMD" | tail -1`
                        ;;
                esac

                if [ "X$pidtest" = "X" ]
                then
                    # This is a stale pid file.
                    rm -f "$PIDFILE"
                    echo "Removed stale pid file: $PIDFILE"
                    pid=""
                fi
            fi
        else
            echo "Cannot read $PIDFILE."
            exit 1
        fi
    fi
}

testpid() {
    pid=`$PSEXE -p $pid | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
    if [ "X$pid" = "X" ]
    then
        # Process is gone so remove the pid file.
        rm -f "$PIDFILE"
        pid=""
    fi
}

console() {
    echo "Running $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        # The string passed to eval must handles spaces in paths correctly.
        COMMAND_LINE="$CMDNICE \"$WRAPPER_CMD\" \"$WRAPPER_CONF\" wrapper.syslog.ident=$APP_NAME wrapper.pidfile=\"$PIDFILE\" $ANCHORPROP $LOCKPROP"
        eval $COMMAND_LINE
    else
        echo "$APP_LONG_NAME is already running."
        exit 1
    fi
}
 
start() {
    echo -n "Starting $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        # The string passed to eval must handles spaces in paths correctly.
        COMMAND_LINE="$CMDNICE \"$WRAPPER_CMD\" \"$WRAPPER_CONF\" wrapper.syslog.ident=$APP_NAME wrapper.pidfile=\"$PIDFILE\" wrapper.daemonize=TRUE $ANCHORPROP $IGNOREPROP $LOCKPROP"
        eval $COMMAND_LINE
    else
        echo "$APP_LONG_NAME is already running."
        exit 1
    fi

    # Sleep for a few seconds to allow for intialization if required 
    #  then test to make sure we're still running.
    #
    i=0
    while [ $i -lt $WAIT_AFTER_STARTUP ]
    do
        sleep 1
        echo -n "."
        i=`expr $i + 1`
    done
    if [ $WAIT_AFTER_STARTUP -gt 0 ]
    then
        getpid
        if [ "X$pid" = "X" ]
        then
            echo " WARNING: $APP_LONG_NAME may have failed to start."
            exit 1
        else
            echo " running ($pid)."
        fi
    else 
        echo ""
    fi
}
 
stopit() {
    echo "Stopping $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        echo "$APP_LONG_NAME was not running."
    else
        if [ "X$IGNORE_SIGNALS" = "X" ]
        then
            # Running so try to stop it.
            kill $pid
            if [ $? -ne 0 ]
            then
                # An explanation for the failure should have been given
                echo "Unable to stop $APP_LONG_NAME."
                exit 1
            fi
        else
            rm -f "$ANCHORFILE"
            if [ -f "$ANCHORFILE" ]
            then
                # An explanation for the failure should have been given
                echo "Unable to stop $APP_LONG_NAME."
                exit 1
            fi
        fi

        # We can not predict how long it will take for the wrapper to
        #  actually stop as it depends on settings in wrapper.conf.
        #  Loop until it does.
        savepid=$pid
        CNT=0
        TOTCNT=0
        while [ "X$pid" != "X" ]
        do
            # Show a waiting message every 5 seconds.
            if [ "$CNT" -lt "5" ]
            then
                CNT=`expr $CNT + 1`
            else
                echo "Waiting for $APP_LONG_NAME to exit..."
                CNT=0
            fi
            TOTCNT=`expr $TOTCNT + 1`

            sleep 1

            testpid
        done

        pid=$savepid
        testpid
        if [ "X$pid" != "X" ]
        then
            echo "Failed to stop $APP_LONG_NAME."
            exit 1
        else
            echo "Stopped $APP_LONG_NAME."
        fi
    fi
}

status() {
    getpid
    if [ "X$pid" = "X" ]
    then
        echo "$APP_LONG_NAME is not running."
        exit 1
    else
        echo "$APP_LONG_NAME is running ($pid)."
        exit 0
    fi
}

dump() {
    echo "Dumping $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        echo "$APP_LONG_NAME was not running."

    else
        kill -3 $pid

        if [ $? -ne 0 ]
        then
            echo "Failed to dump $APP_LONG_NAME."
            exit 1
        else
            echo "Dumped $APP_LONG_NAME."
        fi
    fi
}

case "$1" in

    'console')
        checkUser touchlock $1
        console
        ;;

    'start')
        checkUser touchlock $1
        start
        ;;

    'stop')
        checkUser "" $1
        stopit
        ;;

    'restart')
        checkUser touchlock $1
        stopit
        start
        ;;

    'status')
        checkUser "" $1
        status
        ;;

    'dump')
        checkUser "" $1
        dump
        ;;

    *)
        echo "Usage: $0 { console | start | stop | restart | status | dump }"
        exit 1
        ;;
esac

exit 0

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Leif M. <le...@ta...> - 2007-03-14 05:35:32

Mark,
    Hi again.  The following change will make this problem less likely, 
but it will still be
encountered for narrow parent shells, or for long paths.  Make this 
change in the
getpid function of the script.
---
                case "$DIST_OS" in
                    'macosx')
                        pidtest=`$PSEXE -p $pid -o command | grep 
"$WRAPPER_CMD" | tail -1`
                        ;;
                    *)
                        pidtest=`$PSEXE -p $pid -o args | grep 
"$WRAPPER_CMD" | tail -1`
                        ;;
                esac
---

    Still working on a better solution.

Cheers,
Leif

Leif Mortenson wrote:
> Mark,
> I played around with this some more today trying to figure out what the 
> problem
> could possibly be.  The very first time I tried this today, I saw the 
> same thing you
> did,  BUT  when I tried to repeat it, I was unable to.  Every other 
> attempt results
> in the script working perfectly.  Are you seeing this intermittently or 
> does it happen
> every time?
>
> Mark Leone wrote:
>   
>> I downloaded the script two different times from the URL you provided. 
>> I even tried reverting back to the script in the 3.2.3 distribution, 
>> just to see what happens. Although I get the stale pid error with both 
>> versions of the script, the distribution version throws some other 
>> error messages relating to a keyword error, I believe; so I'm 
>> satisfied that I'm actually executing the new version of the script.
>>     
> Ok.  That does indeed sound like you are running the correct thing.
>
> We are not seeing the same results, but I am attempting to understand why.
> Could you edit your script and make following modifications in the getpid()
> function:
> ---
>                 case "$DIST_OS" in
>                     'macosx')
>                         echo "pidtest='$PSEXE -p $pid | grep 
> \"$WRAPPER_CMD\" | tail -1'"
>                         pidtest=`$PSEXE -p $pid | grep "$WRAPPER_CMD" | 
> tail -1`
>                         ;;
>                     *)
>                         pidtest=`$PSEXE -p $pid -o args | grep 
> "$WRAPPER_CMD" | tail -1`
>                         ;;
>                 esac
>                 echo "pidtest=[$pidtest]"
> ---
> The changes are to add the two echo statements.  Be careful of the 
> regular single
> quotes in the first echo.
>
> On my system, when I check the status, I get the following:
> ---
> myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
> pidtest='/bin/ps -p 2631 | grep 
> "/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
> pidtest=[ 2631 p2 S+ 0:00.15 
> /Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper  
> /Users/myuser/dev/sourceforge/wrappe]
> Action Test Case is running (2631).
> ---
>
> AHHHH  I figured it out as I wrote this.   See that the second pidtest 
> value output is
> clipped at the end?  That is because the output is coming from the piped 
> output of the
> ps command.   For some reason, OSX is truncating the output lines to the 
> width of
> the parent shell even though that process is running in the background.
>
> If the shell width is wide, then this will work correctly.  If however, 
> the shell with is
> narrow enough that the wrapper process name is not fully listed then the 
> grep will
> fail.   See this example:
> ---
> myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
> pidtest='/bin/ps -p 2631 | grep 
> "/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
> pidtest=[]
> Removed stale pid file: 
> /Users/myuser/dev/sourceforge/wrapper/test/./action.pid
> Action Test Case is not running.
> ---
>
> In the above case, ps returns the following:
> ---
>   PID  TT  STAT      TIME COMMAND
>  2631  p2  R+     0:00.35 /Users/myuser/dev/sourceforge/wrapper/t
> ---
> So the grep is failing.
>
> Anyone have any ideas on how to resolve this?  I will look into it as 
> well...
>
> Cheers,
> Leif
>

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Leif M. <le...@ta...> - 2007-03-14 05:49:25

Attachments: sh.script.in

Sorry for all the mails

Mark,
    I figured it out.  ps on OSX has a -w argument which tells ps to use 
132 columns.
If you do it twice then it uses as many columns as necessary.  It seems 
to work the
same whether it is being run directly from a shell or from within a 
subprocess.

    Anyway.  I have attached the fixed shell script with the following fix:
---
                case "$DIST_OS" in
                    'macosx')
                        pidtest=`$PSEXE -ww -p $pid -o command | grep 
"$WRAPPER_CMD" | tail -1`
                        ;;
                    *)
                        pidtest=`$PSEXE -p $pid -o args | grep 
"$WRAPPER_CMD" | tail -1`
                        ;;
                esac
---

    Please let me know how it works for you.

Cheers,
Leif

Leif Mortenson wrote:
> Mark,
>     Hi again.  The following change will make this problem less likely, 
> but it will still be
> encountered for narrow parent shells, or for long paths.  Make this 
> change in the
> getpid function of the script.
> ---
>                 case "$DIST_OS" in
>                     'macosx')
>                         pidtest=`$PSEXE -p $pid -o command | grep 
> "$WRAPPER_CMD" | tail -1`
>                         ;;
>                     *)
>                         pidtest=`$PSEXE -p $pid -o args | grep 
> "$WRAPPER_CMD" | tail -1`
>                         ;;
>                 esac
> ---
>
>     Still working on a better solution.
>
> Cheers,
> Leif
>
> Leif Mortenson wrote:
>   
>> Mark,
>> I played around with this some more today trying to figure out what the 
>> problem
>> could possibly be.  The very first time I tried this today, I saw the 
>> same thing you
>> did,  BUT  when I tried to repeat it, I was unable to.  Every other 
>> attempt results
>> in the script working perfectly.  Are you seeing this intermittently or 
>> does it happen
>> every time?
>>
>> Mark Leone wrote:
>>   
>>     
>>> I downloaded the script two different times from the URL you provided. 
>>> I even tried reverting back to the script in the 3.2.3 distribution, 
>>> just to see what happens. Although I get the stale pid error with both 
>>> versions of the script, the distribution version throws some other 
>>> error messages relating to a keyword error, I believe; so I'm 
>>> satisfied that I'm actually executing the new version of the script.
>>>     
>>>       
>> Ok.  That does indeed sound like you are running the correct thing.
>>
>> We are not seeing the same results, but I am attempting to understand why.
>> Could you edit your script and make following modifications in the getpid()
>> function:
>> ---
>>                 case "$DIST_OS" in
>>                     'macosx')
>>                         echo "pidtest='$PSEXE -p $pid | grep 
>> \"$WRAPPER_CMD\" | tail -1'"
>>                         pidtest=`$PSEXE -p $pid | grep "$WRAPPER_CMD" | 
>> tail -1`
>>                         ;;
>>                     *)
>>                         pidtest=`$PSEXE -p $pid -o args | grep 
>> "$WRAPPER_CMD" | tail -1`
>>                         ;;
>>                 esac
>>                 echo "pidtest=[$pidtest]"
>> ---
>> The changes are to add the two echo statements.  Be careful of the 
>> regular single
>> quotes in the first echo.
>>
>> On my system, when I check the status, I get the following:
>> ---
>> myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
>> pidtest='/bin/ps -p 2631 | grep 
>> "/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
>> pidtest=[ 2631 p2 S+ 0:00.15 
>> /Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper  
>> /Users/myuser/dev/sourceforge/wrappe]
>> Action Test Case is running (2631).
>> ---
>>
>> AHHHH  I figured it out as I wrote this.   See that the second pidtest 
>> value output is
>> clipped at the end?  That is because the output is coming from the piped 
>> output of the
>> ps command.   For some reason, OSX is truncating the output lines to the 
>> width of
>> the parent shell even though that process is running in the background.
>>
>> If the shell width is wide, then this will work correctly.  If however, 
>> the shell with is
>> narrow enough that the wrapper process name is not fully listed then the 
>> grep will
>> fail.   See this example:
>> ---
>> myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
>> pidtest='/bin/ps -p 2631 | grep 
>> "/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
>> pidtest=[]
>> Removed stale pid file: 
>> /Users/myuser/dev/sourceforge/wrapper/test/./action.pid
>> Action Test Case is not running.
>> ---
>>
>> In the above case, ps returns the following:
>> ---
>>   PID  TT  STAT      TIME COMMAND
>>  2631  p2  R+     0:00.35 /Users/myuser/dev/sourceforge/wrapper/t
>> ---
>> So the grep is failing.
>>
>> Anyone have any ideas on how to resolve this?  I will look into it as 
>> well...
>>
>> Cheers,
>> Leif
>>   
>>     
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Leif M. <le...@ta...> - 2007-03-14 05:30:24

Mark,
I played around with this some more today trying to figure out what the 
problem
could possibly be.  The very first time I tried this today, I saw the 
same thing you
did,  BUT  when I tried to repeat it, I was unable to.  Every other 
attempt results
in the script working perfectly.  Are you seeing this intermittently or 
does it happen
every time?

Mark Leone wrote:
> I downloaded the script two different times from the URL you provided. 
> I even tried reverting back to the script in the 3.2.3 distribution, 
> just to see what happens. Although I get the stale pid error with both 
> versions of the script, the distribution version throws some other 
> error messages relating to a keyword error, I believe; so I'm 
> satisfied that I'm actually executing the new version of the script.
Ok.  That does indeed sound like you are running the correct thing.

We are not seeing the same results, but I am attempting to understand why.
Could you edit your script and make following modifications in the getpid()
function:
---
                case "$DIST_OS" in
                    'macosx')
                        echo "pidtest='$PSEXE -p $pid | grep 
\"$WRAPPER_CMD\" | tail -1'"
                        pidtest=`$PSEXE -p $pid | grep "$WRAPPER_CMD" | 
tail -1`
                        ;;
                    *)
                        pidtest=`$PSEXE -p $pid -o args | grep 
"$WRAPPER_CMD" | tail -1`
                        ;;
                esac
                echo "pidtest=[$pidtest]"
---
The changes are to add the two echo statements.  Be careful of the 
regular single
quotes in the first echo.

On my system, when I check the status, I get the following:
---
myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
pidtest='/bin/ps -p 2631 | grep 
"/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
pidtest=[ 2631 p2 S+ 0:00.15 
/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper  
/Users/myuser/dev/sourceforge/wrappe]
Action Test Case is running (2631).
---

AHHHH  I figured it out as I wrote this.   See that the second pidtest 
value output is
clipped at the end?  That is because the output is coming from the piped 
output of the
ps command.   For some reason, OSX is truncating the output lines to the 
width of
the parent shell even though that process is running in the background.

If the shell width is wide, then this will work correctly.  If however, 
the shell with is
narrow enough that the wrapper process name is not fully listed then the 
grep will
fail.   See this example:
---
myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
pidtest='/bin/ps -p 2631 | grep 
"/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
pidtest=[]
Removed stale pid file: 
/Users/myuser/dev/sourceforge/wrapper/test/./action.pid
Action Test Case is not running.
---

In the above case, ps returns the following:
---
  PID  TT  STAT      TIME COMMAND
 2631  p2  R+     0:00.35 /Users/myuser/dev/sourceforge/wrapper/t
---
So the grep is failing.

Anyone have any ideas on how to resolve this?  I will look into it as 
well...

Cheers,
Leif

Re: [Wrapper-user] Can't make old wrapper daemon go away

From: Mark L. <ma...@le...> - 2007-03-14 13:25:34

Leif,

Many, many thanks. No problem with all the e-mails, as they had a happy 
ending. :) Thanks for running this down and correcting it. I ran your 
new script and it works perfectly. Now it all makes sense. The only 
change I made when it stopped working was that I put my app one level 
deeper in the file system so that the path was increased by a few 
characters. It seemed so inconsequential to me that it didn't even occur 
to me when I racked my brain trying to figure out what was different 
when it stopped working. Good illustration of the basic rule of 
troubleshooting: assume that no change is inconsequential, and record 
even the smallest ones. Thanks again.

-Mark

Leif Mortenson wrote:
> Sorry for all the mails
>
> Mark,
>    I figured it out.  ps on OSX has a -w argument which tells ps to 
> use 132 columns.
> If you do it twice then it uses as many columns as necessary.  It 
> seems to work the
> same whether it is being run directly from a shell or from within a 
> subprocess.
>
>    Anyway.  I have attached the fixed shell script with the following 
> fix:
> ---
>                case "$DIST_OS" in
>                    'macosx')
>                        pidtest=`$PSEXE -ww -p $pid -o command | grep 
> "$WRAPPER_CMD" | tail -1`
>                        ;;
>                    *)
>                        pidtest=`$PSEXE -p $pid -o args | grep 
> "$WRAPPER_CMD" | tail -1`
>                        ;;
>                esac
> ---
>
>    Please let me know how it works for you.
>
> Cheers,
> Leif
>
> Leif Mortenson wrote:
>> Mark,
>>     Hi again.  The following change will make this problem less 
>> likely, but it will still be
>> encountered for narrow parent shells, or for long paths.  Make this 
>> change in the
>> getpid function of the script.
>> ---
>>                 case "$DIST_OS" in
>>                     'macosx')
>>                         pidtest=`$PSEXE -p $pid -o command | grep 
>> "$WRAPPER_CMD" | tail -1`
>>                         ;;
>>                     *)
>>                         pidtest=`$PSEXE -p $pid -o args | grep 
>> "$WRAPPER_CMD" | tail -1`
>>                         ;;
>>                 esac
>> ---
>>
>>     Still working on a better solution.
>>
>> Cheers,
>> Leif
>>
>> Leif Mortenson wrote:
>>  
>>> Mark,
>>> I played around with this some more today trying to figure out what 
>>> the problem
>>> could possibly be.  The very first time I tried this today, I saw 
>>> the same thing you
>>> did,  BUT  when I tried to repeat it, I was unable to.  Every other 
>>> attempt results
>>> in the script working perfectly.  Are you seeing this intermittently 
>>> or does it happen
>>> every time?
>>>
>>> Mark Leone wrote:
>>>      
>>>> I downloaded the script two different times from the URL you 
>>>> provided. I even tried reverting back to the script in the 3.2.3 
>>>> distribution, just to see what happens. Although I get the stale 
>>>> pid error with both versions of the script, the distribution 
>>>> version throws some other error messages relating to a keyword 
>>>> error, I believe; so I'm satisfied that I'm actually executing the 
>>>> new version of the script.
>>>>           
>>> Ok.  That does indeed sound like you are running the correct thing.
>>>
>>> We are not seeing the same results, but I am attempting to 
>>> understand why.
>>> Could you edit your script and make following modifications in the 
>>> getpid()
>>> function:
>>> ---
>>>                 case "$DIST_OS" in
>>>                     'macosx')
>>>                         echo "pidtest='$PSEXE -p $pid | grep 
>>> \"$WRAPPER_CMD\" | tail -1'"
>>>                         pidtest=`$PSEXE -p $pid | grep 
>>> "$WRAPPER_CMD" | tail -1`
>>>                         ;;
>>>                     *)
>>>                         pidtest=`$PSEXE -p $pid -o args | grep 
>>> "$WRAPPER_CMD" | tail -1`
>>>                         ;;
>>>                 esac
>>>                 echo "pidtest=[$pidtest]"
>>> ---
>>> The changes are to add the two echo statements.  Be careful of the 
>>> regular single
>>> quotes in the first echo.
>>>
>>> On my system, when I check the status, I get the following:
>>> ---
>>> myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
>>> pidtest='/bin/ps -p 2631 | grep 
>>> "/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
>>> pidtest=[ 2631 p2 S+ 0:00.15 
>>> /Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper  
>>> /Users/myuser/dev/sourceforge/wrappe]
>>> Action Test Case is running (2631).
>>> ---
>>>
>>> AHHHH  I figured it out as I wrote this.   See that the second 
>>> pidtest value output is
>>> clipped at the end?  That is because the output is coming from the 
>>> piped output of the
>>> ps command.   For some reason, OSX is truncating the output lines to 
>>> the width of
>>> the parent shell even though that process is running in the background.
>>>
>>> If the shell width is wide, then this will work correctly.  If 
>>> however, the shell with is
>>> narrow enough that the wrapper process name is not fully listed then 
>>> the grep will
>>> fail.   See this example:
>>> ---
>>> myhost:~/dev/sourceforge/wrapper/test myuser$ ./action status
>>> pidtest='/bin/ps -p 2631 | grep 
>>> "/Users/myuser/dev/sourceforge/wrapper/test/../bin/wrapper" | tail -1'
>>> pidtest=[]
>>> Removed stale pid file: 
>>> /Users/myuser/dev/sourceforge/wrapper/test/./action.pid
>>> Action Test Case is not running.
>>> ---
>>>
>>> In the above case, ps returns the following:
>>> ---
>>>   PID  TT  STAT      TIME COMMAND
>>>  2631  p2  R+     0:00.35 /Users/myuser/dev/sourceforge/wrapper/t
>>> ---
>>> So the grep is failing.
>>>
>>> Anyone have any ideas on how to resolve this?  I will look into it 
>>> as well...
>>>
>>> Cheers,
>>> Leif
>>>       
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to 
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV 
>>
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>   
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>