wrapper-user — User issues for Wrapper. (Support questions, etc.)

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

[Leif M. <le...@ta...>]

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

[Leif M. <le...@ta...>]

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

[Leif M. <le...@ta...>]

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] Building on OpenBSD + AMD64 prob

[Peter T. <pet...@ya...>]

--- Ben Jansen <bj...@tr...> wrote:
> Try adding -fPIC to your CFLAGS & recompiling.

Already tried .. same issue

Re: [Wrapper-user] Building on OpenBSD + AMD64 prob

[Ben J. <bj...@tr...>]

Try adding -fPIC to your CFLAGS & recompiling.

- Ben


-----Original Message-----
From: wra...@li... on behalf of Peter =
Thoenen
Sent: Fri 3/9/2007 12:23 PM
To: wra...@li...
Subject: [Wrapper-user] Building on OpenBSD + AMD64 prob
=20
Alright so been digging throught the archives and src to get this to
compile on OBSD (mainly mod'ing the hell out of the FreeBSD makefile
and some other items like s/FREEBSD/OPENBSD).  The problem I am hitting
now and google isn't helping I think is AMD64 specific .. ideas? (see
below):

07-03-09 15:20:23 /usr/local/src/wrapper_3.2.3_src # ./build64.sh=20

Wrapper Build System
--------------------
Buildfile: build.xml

init:msg:
**********************************************************************
About to build a 64-bit version of the Java Service Wrapper 3.2.3.
The OS Name is "OpenBSD", resolved from "OpenBSD".
The Architecture is "x86", resolved from "amd64".
The distribution name will be: wrapper-OpenBSD-x86-64-3.2.3
**********************************************************************

update-info:
Copying 1 file to
/usr/local/src/wrapper_3.2.3_src/src/java/org/tanukisoftware/wrapper
Copying 1 file to /usr/local/src/wrapper_3.2.3_src/src/c

compile-java-warn:
**********************************************************************
WARNING
The jar is being built for Java version 1.4.  This will not be
compatible with older JVMs.
**********************************************************************

compile-java:
Compiling 1 source file to
/usr/local/src/wrapper_3.2.3_src/build/classes
ClassArgument.name=3Dorg.tanukisoftware.wrapper.WrapperManager

compile-c-unix:
if test ! -d .deps; then mkdir .deps; fi
gcc -Wall -pedantic -DOPENBSD -DPIC wrapper.c wrapperinfo.c
wrappereventloop.c wrapper_unix.c property.c logger.c -lm -lcompat
-pthread -o ../../bin/wrapper
/tmp//ccF22459.o(.text+0xc54): In function `wrapperProtocolFunction':
: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//ccF22459.o(.text+0x29): In function
`wrapperAddDefaultProperties':
: warning: sprintf() is often misused, please use snprintf()
gcc -Wall -pedantic -DOPENBSD -DPIC -I/usr/local/jdk-1.5.0/include
-I/usr/local/jdk-1.5.0/include/openbsd    -c -o wrapperinfo.o
wrapperinfo.c
gcc -Wall -pedantic -DOPENBSD -DPIC -shared wrapperjni_unix.o
wrapperinfo.o wrapperjni.o -o ../../lib/libwrapper.so
/usr/bin/ld: wrapperjni_unix.o: relocation R_X86_64_32 can not be used
when making a shared object; recompile with -fPIC
wrapperjni_unix.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake: *** [libwrapper.so] Error 1

BUILD FAILED
/usr/local/src/wrapper_3.2.3_src/build.xml:580: exec returned: 2

Total time: 7 seconds

-------------------------------------------------------------------------=

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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] Building on OpenBSD + AMD64 prob

[Peter T. <pet...@ya...>]

Alright so been digging throught the archives and src to get this to
compile on OBSD (mainly mod'ing the hell out of the FreeBSD makefile
and some other items like s/FREEBSD/OPENBSD).  The problem I am hitting
now and google isn't helping I think is AMD64 specific .. ideas? (see
below):

07-03-09 15:20:23 /usr/local/src/wrapper_3.2.3_src # ./build64.sh 

Wrapper Build System
--------------------
Buildfile: build.xml

init:msg:
**********************************************************************
About to build a 64-bit version of the Java Service Wrapper 3.2.3.
The OS Name is "OpenBSD", resolved from "OpenBSD".
The Architecture is "x86", resolved from "amd64".
The distribution name will be: wrapper-OpenBSD-x86-64-3.2.3
**********************************************************************

update-info:
Copying 1 file to
/usr/local/src/wrapper_3.2.3_src/src/java/org/tanukisoftware/wrapper
Copying 1 file to /usr/local/src/wrapper_3.2.3_src/src/c

compile-java-warn:
**********************************************************************
WARNING
The jar is being built for Java version 1.4.  This will not be
compatible with older JVMs.
**********************************************************************

compile-java:
Compiling 1 source file to
/usr/local/src/wrapper_3.2.3_src/build/classes
ClassArgument.name=org.tanukisoftware.wrapper.WrapperManager

compile-c-unix:
if test ! -d .deps; then mkdir .deps; fi
gcc -Wall -pedantic -DOPENBSD -DPIC wrapper.c wrapperinfo.c
wrappereventloop.c wrapper_unix.c property.c logger.c -lm -lcompat
-pthread -o ../../bin/wrapper
/tmp//ccF22459.o(.text+0xc54): In function `wrapperProtocolFunction':
: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//ccF22459.o(.text+0x29): In function
`wrapperAddDefaultProperties':
: warning: sprintf() is often misused, please use snprintf()
gcc -Wall -pedantic -DOPENBSD -DPIC -I/usr/local/jdk-1.5.0/include
-I/usr/local/jdk-1.5.0/include/openbsd    -c -o wrapperinfo.o
wrapperinfo.c
gcc -Wall -pedantic -DOPENBSD -DPIC -shared wrapperjni_unix.o
wrapperinfo.o wrapperjni.o -o ../../lib/libwrapper.so
/usr/bin/ld: wrapperjni_unix.o: relocation R_X86_64_32 can not be used
when making a shared object; recompile with -fPIC
wrapperjni_unix.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake: *** [libwrapper.so] Error 1

BUILD FAILED
/usr/local/src/wrapper_3.2.3_src/build.xml:580: exec returned: 2

Total time: 7 seconds

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

[Mark L. <mid...@ve...>]

#! /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

[Leif M. <le...@ta...>]

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

[Wrapper-user] Is the list down?

[Mark L. <mid...@ve...>]

I've seen no traffic in six days except my own unanswered questions. I 
registered with another address that goes to my own mail server with no 
spam filters, still nothing. Unless I'm missing some messages, version 
3.2.3 for Mac OSX ppc seems to be entirely broken for Integration method 
1. I do exactly what the docs say, and it does not work. I'm out of 
ideas, tried everything I can think of.

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

[Mark L. <mid...@ve...>]

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] waiting on next release

[Leif M. <le...@ta...>]

Markus,
Sorry all.  I know it has been taking a while.  This year has turned out 
to be
very busy and I have been trying to work on the Wrapper is time permits.
Good news is that I was finally able to get the Windows 64-bit version to
build last night.  I gave up up the MSVC project files and ended up creating
a Makefile for nmake.  That appeared to have worked.  It has not yet been
tested at all, and there are a few bugs that I need to get fixed before 
things
can be released.

As for the Compile farm.  I have been working on getting Solaris x86 set
up using VMWare, so I should be able to provide that version myself.
The sparc Solaris versions are going to be a problem however.  I am going
to have to locate a user willing to help out with those builds in the short
term at least.

Cheers,
Leif

Markus Müller wrote:
> Hi Leif,
> I am sorry beeing annoying, but I am still looking for next release. I know, the compile farm has been officially discontinued since 2007-02-08. So how it will go on? Is there any chance to get an release within a short time?
> Markus
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: wra...@li... [mailto:wra...@li...] Im Auftrag von Leif Mortenson
> Gesendet: Montag, 22. Januar 2007 14:15
> An: wra...@li...
> Betreff: Re: [Wrapper-user] why #include-file is not reloaded
>
> Markus,
>     Sorry for the slip.  I was working on it, but ran into some problems 
> getting the
> 64-bit windows version to work.  I finally got a WindowsXP Pro 64 system up
> and running and will hopefully be able to get to a point where I can 
> compile and
> resolve the problems this week.
>     Finding the OS was quite an adventure.  Microsoft only sells it with 
> an OEM
> license.  I lucked out and found a company selling it bundled with a $20 
> floppy
> drive.  Gotta love it.
>     In addition, the Sourceforge compile farm has been down since the 
> beginning of
> the year.  I will not be able to do a full release until it is back up, 
> but I may give up
> and do a partial release (ie no Solaris) if it doesn't get fixed soon.
> http://sourceforge.net/docs/A05/en/#top
>
> Cheers,
> Leif
>
>
> Markus Müller wrote:
>   
>> Hi Leif,
>> I was looking forward to next release you announced for end of december 2006. Probably you had much to do. So now I am interested in new date of publishing next release (after 3.2.3) for download.
>> Cheers,
>> Markus
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: wra...@li... [mailto:wra...@li...] Im Auftrag von Leif Mortenson
>> Gesendet: Freitag, 15. Dezember 2006 08:00
>> An: wra...@li...
>> Betreff: Re: [Wrapper-user] why #include-file is not reloaded
>>
>> Markus,
>>     I tested this out a little bit.   Properties in include files are 
>> correctly being reloaded
>> That is not your problem.  It is actually with the working dir.
>>
>>     The problem is that the Wrapper loads the configuration files the 
>> first time when its
>> working directory is the location of the wrapper.exe.  As stated in the 
>> docs, once the
>> configuration file is fully loaded, the working directory will be 
>> changed as per the
>> value specified with wrapper.working.dir.
>>     This means that the first time around, your include file reference 
>> is correct.
>> However, when it attempts to go back and reload the config file later, 
>> this relative
>> reverence is no longer valid your include file is being looked for at
>> ../../startup.conf relative to the wrapper.exe
>>
>>     I view this as a bug in the wrapper that I'll fix for the next 
>> release at the end of the
>> month.  For now, you can work around this by using the following two include
>> references.  This works because the wrapper ignores include files that 
>> do not exist.
>>
>> #include ../startup.conf
>> #include startup.conf
>>
>> Cheers,
>> Leif
>>
>> Markus Müller wrote:
>>   
>>     
>>> Hi together,
>>> my wrapper.conf contains following lines:
>>>
>>> wrapper.java.mainclass=myclass1
>>> wrapper.working.dir=../
>>> #include ../startup.conf
>>> wrapper.restart.reload_configuration=TRUE
>>>
>>> startup.conf conatins only one line:
>>>
>>> wrapper.java.mainclass=myclass2
>>>
>>> If i start wrapper, myclass2 will start perfectly. But if i do WrapperManager.restart(); in my code, myclass1 starts up. I did various test and I think, while reolading the configuration, #include-files are not used. Any idea, why not?
>>> I'm using wrapper Version 3.2.3. myclass1 and myclass2 implements WrapperListener.
>>>
>>>   
>>>     
>>>       
>> -------------------------------------------------------------------------
>> 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
>>
>>   
>>     
>
>
> -------------------------------------------------------------------------
> 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
>
>   

[Wrapper-user] waiting on next release

[<m.m...@ac...>]

Hi Leif,
I am sorry beeing annoying, but I am still looking for next release. I =
know, the compile farm has been officially discontinued since =
2007-02-08. So how it will go on? Is there any chance to get an release =
within a short time?
Markus




-----Urspr=FCngliche Nachricht-----
Von: wra...@li... =
[mailto:wra...@li...] Im Auftrag von Leif =
Mortenson
Gesendet: Montag, 22. Januar 2007 14:15
An: wra...@li...
Betreff: Re: [Wrapper-user] why #include-file is not reloaded

Markus,
    Sorry for the slip.  I was working on it, but ran into some problems =

getting the
64-bit windows version to work.  I finally got a WindowsXP Pro 64 system =
up
and running and will hopefully be able to get to a point where I can=20
compile and
resolve the problems this week.
    Finding the OS was quite an adventure.  Microsoft only sells it with =

an OEM
license.  I lucked out and found a company selling it bundled with a $20 =

floppy
drive.  Gotta love it.
    In addition, the Sourceforge compile farm has been down since the=20
beginning of
the year.  I will not be able to do a full release until it is back up,=20
but I may give up
and do a partial release (ie no Solaris) if it doesn't get fixed soon.
http://sourceforge.net/docs/A05/en/#top

Cheers,
Leif


Markus M=FCller wrote:
> Hi Leif,
> I was looking forward to next release you announced for end of =
december 2006. Probably you had much to do. So now I am interested in =
new date of publishing next release (after 3.2.3) for download.
> Cheers,
> Markus
>
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: wra...@li... =
[mailto:wra...@li...] Im Auftrag von Leif =
Mortenson
> Gesendet: Freitag, 15. Dezember 2006 08:00
> An: wra...@li...
> Betreff: Re: [Wrapper-user] why #include-file is not reloaded
>
> Markus,
>     I tested this out a little bit.   Properties in include files are=20
> correctly being reloaded
> That is not your problem.  It is actually with the working dir.
>
>     The problem is that the Wrapper loads the configuration files the=20
> first time when its
> working directory is the location of the wrapper.exe.  As stated in =
the=20
> docs, once the
> configuration file is fully loaded, the working directory will be=20
> changed as per the
> value specified with wrapper.working.dir.
>     This means that the first time around, your include file reference =

> is correct.
> However, when it attempts to go back and reload the config file later, =

> this relative
> reverence is no longer valid your include file is being looked for at
> ../../startup.conf relative to the wrapper.exe
>
>     I view this as a bug in the wrapper that I'll fix for the next=20
> release at the end of the
> month.  For now, you can work around this by using the following two =
include
> references.  This works because the wrapper ignores include files that =

> do not exist.
>
> #include ../startup.conf
> #include startup.conf
>
> Cheers,
> Leif
>
> Markus M=FCller wrote:
>  =20
>> Hi together,
>> my wrapper.conf contains following lines:
>>
>> wrapper.java.mainclass=3Dmyclass1
>> wrapper.working.dir=3D../
>> #include ../startup.conf
>> wrapper.restart.reload_configuration=3DTRUE
>>
>> startup.conf conatins only one line:
>>
>> wrapper.java.mainclass=3Dmyclass2
>>
>> If i start wrapper, myclass2 will start perfectly. But if i do =
WrapperManager.restart(); in my code, myclass1 starts up. I did various =
test and I think, while reolading the configuration, #include-files are =
not used. Any idea, why not?
>> I'm using wrapper Version 3.2.3. myclass1 and myclass2 implements =
WrapperListener.
>>
>>  =20
>>    =20
>
>
> =
-------------------------------------------------------------------------=

> 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=3Djoin.php&p=3Dsourceforge&CID=3D=
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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  =20


-------------------------------------------------------------------------=

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=3Djoin.php&p=3Dsourceforge&CID=3D=
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

[Mark L. <mid...@ve...>]

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.

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

[Mark L. <mid...@ve...>]

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] FW: Need information regarding packaging the wrapper as an EXE

[Mark L. <mid...@ve...>]

Aparna Khade wrote:
>
> Is there a way in which I can package these 4 folders into an exe to 
> be given to the client?
> Appreciate your prompt response.
>
Have a look at NSIS at http://nsis.sourceforge.net/Main_Page

It's a free open source tool that lets you write installation scripts 
for Windows that let you do just about anything. It takes a little time 
to learn the scripting language (a couple days if you're used to picking 
up things like this), but there's lots of help available, including a 
nice user's guide and a discussion forum.

-Mark

[Wrapper-user] FW: Need information regarding packaging the wrapper as an EXE

[Aparna K. <ap...@da...>]

Hi,

Can I please get an update to this email.

Thanks,
Aparna Khade

> ______________________________________________=20
> From: 	Aparna Khade =20
> Sent:	Wednesday, February 28, 2007 10:03 AM
> To:	'wra...@li...'
> Subject:	Need information regarding packaging the wrapper as an
> EXE
>=20
> Hi,
>=20
> I tried the Java Wrapper service by following the instructions for
> Method 1 under the Integrate section.
> By doing this, I was able to execute the application by using the
> appropriate .bat file (MyApp.bat)
> As far as I have understood, this approach requires that there be 4
> folders: bin, lib, conf & logs.
>=20
> Is there a way in which I can package these 4 folders into an exe to
> be given to the client?
> Appreciate your prompt response.
>=20
>=20
> Thanks & Regards,
> Aparna Khade
> Data, Inc.
> 72 Summit Ave, Montvale, NJ 07645
> Tel: 201-799-4982
>=20
>=20

Re: [Wrapper-user] Need information regarding packaging the wrapper asan EXE

[Karthik R. <ka...@ch...>]

Aparna, 

Yes by default it requires 4 folders - you can change this if you want. 

 

When you say an exe - what do you want, just a single file that you can send
to the client or when installed at the client site do you want just one exe
to be there on the hard disk - say myapp.exe? 

 

To just distribute the file you could create a self-extracting zip file
(using software like winzip) which you can send to the client; when the user
executes the exe it will expand and create the 4 folders with your MyApp.bat
which the user can then use. 

 

If you want a single folder on the client machine after install say
c:\program files\MyApp\ without the 4 diff folders I believe you can edit
the conf files and the batch files to look for all the files in one folder. 

 

Hope this helps. 

 

--karthik

 

  _____  

From: wra...@li...
[mailto:wra...@li...] On Behalf Of Aparna
Khade
Sent: Wednesday, February 28, 2007 7:03 AM
To: wra...@li...
Subject: [Wrapper-user] Need information regarding packaging the wrapper
asan EXE

 

Hi, 

I tried the Java Wrapper service by following the instructions for Method 1
under the Integrate section. 
By doing this, I was able to execute the application by using the
appropriate .bat file (MyApp.bat) 
As far as I have understood, this approach requires that there be 4 folders:
bin, lib, conf & logs. 

Is there a way in which I can package these 4 folders into an exe to be
given to the client? 
Appreciate your prompt response. 

 

Thanks & Regards, 
Aparna Khade 
Data, Inc. 
72 Summit Ave, Montvale, NJ 07645 
Tel: 201-799-4982 

 

[Wrapper-user] Need information regarding packaging the wrapper as an EXE

[Aparna K. <ap...@da...>]

> Hi,
>=20
> I tried the Java Wrapper service by following the instructions for
> Method 1 under the Integrate section.
> By doing this, I was able to execute the application by using the
> appropriate .bat file (MyApp.bat)
> As far as I have understood, this approach requires that there be 4
> folders: bin, lib, conf & logs.
>=20
> Is there a way in which I can package these 4 folders into an exe to
> be given to the client?
> Appreciate your prompt response.
>=20
>=20
> Thanks & Regards,
> Aparna Khade
> Data, Inc.
> 72 Summit Ave, Montvale, NJ 07645
> Tel: 201-799-4982
>=20
>=20

[Wrapper-user] Wrapper and JRE 1.5.0-11 - migration issues

[Andrei <pho...@pi...>]

Dear Wrapper Community!

We are now trying to migrate some Java application from JRE 1.4.2-11 =20
to JRE 1.5.0. So, we installed the last JRE - 1.5.0-11 to the test =20
environment and tried to run our Application by the Wrapper.
The Application has been modified to integrate with Wrapper.
However, results are quite contraversal - Wrapper stops after some timeout.

In Wrapper log for the JRE 1.5.0 the following is logged
INFO   | jvm 1    | 2007/02/28 12:13:23 | WrapperListener.start runner =20
thread started.
INFO   | jvm 1    | 2007/02/28 12:13:23 | Send a packet START_PENDING : 1000=
0
INFO   | jvm 1    | 2007/02/28 12:13:23 | Starting CASMain!
INFO   | jvm 1    | 2007/02/28 12:13:23 | WrapperListener.start runner =20
thread stopped.
INFO   | jvm 1    | 2007/02/28 12:13:23 | returned from =20
WrapperListener.start()
INFO   | jvm 1    | 2007/02/28 12:13:23 | Send a packet STARTED :
DEBUG  | wrapperp | 2007/02/28 12:13:23 | read a packet START_PENDING : 1000=
0
DEBUG  | wrapper  | 2007/02/28 12:13:23 | JVM signalled a start =20
pending with waitHint of 10000 millis.
DEBUG  | wrapperp | 2007/02/28 12:13:23 | read a packet STARTED :
DEBUG  | wrapper  | 2007/02/28 12:13:23 | JVM signalled that it was started.
INFO   | jvm 1    | 2007/02/28 12:13:23 | Startup runner thread stopped.
INFO   | jvm 1    | 2007/02/28 12:13:24 | Wrapper Manager: =20
ShutdownHook started

and then JVM is shut down

However, with JRE 1.4.2 this is not the case
INFO   | jvm 1    | 2007/02/28 12:14:27 | Startup runner thread stopped.
DEBUG  | wrapperp | 2007/02/28 12:14:27 | read a packet START_PENDING : 1000=
0
DEBUG  | wrapper  | 2007/02/28 12:14:27 | JVM signalled a start =20
pending with waitHint of 10000 millis.
DEBUG  | wrapperp | 2007/02/28 12:14:27 | read a packet STARTED :
DEBUG  | wrapper  | 2007/02/28 12:14:27 | JVM signalled that it was started.
DEBUG  | wrapperp | 2007/02/28 12:14:31 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:31 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:31 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:31 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:31 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:14:35 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:36 | Received a packet PING : ping


So, under JRE 1.5.0 - after event "Startup runner thread stopped." =20
Wrapper performs
"Wrapper Manager: ShutdownHook started".
As you see, this is not the case for JRE 1.4.2.

Question to you - do you have an idea what is the problem, and what =20
could be done to enable running Wrapper and App under JRE 1.5.0?

Thank you, Andrei!

Detailed Log and config files are below.


--- Wrapper config ----
#********************************************************************
# Wrapper Properties
#********************************************************************
# Java Application
# Used to choose either JRE 1.4.2 or 1.5.0
# wrapper.java.command=3DC:\Program Files\Java\jdk1.5.0_11\jre\bin\java
wrapper.java.command=3DC:\Program Files\Java\j2re1.4.2_11\bin\java

# Java Main class.  This class must implement the WrapperListener interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
# wrapper.java.mainclass=3Dorg.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.java.mainclass=3DCASMainServiceStarter

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=3D./wrapper.jar
wrapper.java.classpath.2=3D./css.jar
wrapper.java.classpath.3=3D.
wrapper.java.classpath.4=3D./all.jar
wrapper.java.classpath.5=3D./mail.jar
wrapper.java.classpath.6=3D./activation.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=3D.

# Java Additional Parameters
wrapper.java.additional.1=3D

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=3D32

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=3D128

# Application parameters.  Add parameters as needed starting from 1
#wrapper.app.parameter.1=3D-invisible

# Delay for JVM ping - 120 seconds
wrapper.ping.timeout=3D120

# wrapper.cpu.timeout=3D30
wrapper.startup.timeout=3D0

wrapper.debug=3Dtrue

# WRapper ports
wrapper.jvm.port.min=3D31000
wrapper.jvm.port.max=3D31999

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Format of output for the console.  (See docs for formats)
wrapper.console.format=3DPM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=3DINFO

# Log file to use for wrapper output logging.
wrapper.logfile=3D../sys/wrapper.jre15.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=3DLPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=3DINFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m =3D 10 megabytes.
wrapper.logfile.maxsize=3D0

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=3D0

# Rotation of Log files
wrapper.logfile.rollmode=3DDATE

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=3DINFO

#********************************************************************
# Wrapper NT Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.ntservice.name=3DCASMainJRE15

# Display name of the service
wrapper.ntservice.displayname=3DCASMainJRE15

# Description of the service
wrapper.ntservice.description=3DMain process of CAS Replication

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=3Dlanmanserver
wrapper.ntservice.dependency.2=3DMSSQLSERVER

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=3DAUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=3Dfalse

------ End of Wrapper config ----

---- Wrapper Log with JRE 1.5.0 -----
STATUS | wrapper  | 2007/02/28 12:13:22 | --> Wrapper Started as Console
DEBUG  | wrapper  | 2007/02/28 12:13:22 | Using tick timer.
DEBUG  | wrapperp | 2007/02/28 12:13:22 | server listening on port 32000.
STATUS | wrapper  | 2007/02/28 12:13:22 | Launching a JVM...
DEBUG  | wrapper  | 2007/02/28 12:13:22 | command: =20
"C:\WINDOWS\system32\java.exe" -Xms32m -Xmx128m =20
-Djava.library.path=3D"." -classpath =20
"./wrapper.jar;./css.jar;.;./all.jar;./mail.jar;./activation.jar" =20
-Dwrapper.key=3D"iZUbwb5BexmgbIru" -Dwrapper.port=3D32000 =20
-Dwrapper.jvm.port.min=3D31000 -Dwrapper.jvm.port.max=3D31999 =20
-Dwrapper.debug=3D"TRUE" -Dwrapper.pid=3D5676 -Dwrapper.version=3D"3.2.3" =
=20
-Dwrapper.native_library=3D"wrapper" -Dwrapper.cpu.timeout=3D"10" =20
-Dwrapper.jvmid=3D1 CASMainServiceStarter
DEBUG  | wrapper  | 2007/02/28 12:13:22 | JVM started (PID=3D1632)
INFO   | jvm 1    | 2007/02/28 12:13:22 | WrapperManager class =20
initialized by thread: main  Using classloader: =20
sun.misc.Launcher$AppClassLoader@133056f
INFO   | jvm 1    | 2007/02/28 12:13:22 | Wrapper (Version 3.2.3) =20
http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2007/02/28 12:13:22 |   Copyright 1999-2006 Tanuki =20
Software, Inc.  All Rights Reserved.
INFO   | jvm 1    | 2007/02/28 12:13:22 |
INFO   | jvm 1    | 2007/02/28 12:13:22 | Wrapper Manager: JVM #1
INFO   | jvm 1    | 2007/02/28 12:13:22 | Running a 32-bit JVM.
INFO   | jvm 1    | 2007/02/28 12:13:22 | Wrapper Manager: Registering =20
shutdown hook
INFO   | jvm 1    | 2007/02/28 12:13:22 | Wrapper Manager: Using wrapper
INFO   | jvm 1    | 2007/02/28 12:13:22 | Load native library.  One or =20
more attempts may fail if platform specific libraries do not exist.
INFO   | jvm 1    | 2007/02/28 12:13:22 | Loading native library =20
failed: wrapper-windows-x86-32.dll  Cause: =20
java.lang.UnsatisfiedLinkError: no wrapper-windows-x86-32 in =20
java.library.path
INFO   | jvm 1    | 2007/02/28 12:13:22 | Loaded native library: wrapper.dll
INFO   | jvm 1    | 2007/02/28 12:13:22 | Calling native =20
initialization method.
INFO   | jvm 1    | 2007/02/28 12:13:22 | Initializing WrapperManager =20
native library.
INFO   | jvm 1    | 2007/02/28 12:13:22 | Java Executable: =20
C:\WINDOWS\system32\java.exe
INFO   | jvm 1    | 2007/02/28 12:13:22 | Windows version: 5.2.3790
INFO   | jvm 1    | 2007/02/28 12:13:22 | Java Version   : =20
1.5.0_11-b03 Java HotSpot(TM) Client VM
INFO   | jvm 1    | 2007/02/28 12:13:22 | Java VM Vendor : Sun =20
Microsystems Inc.
INFO   | jvm 1    | 2007/02/28 12:13:22 |
INFO   | jvm 1    | 2007/02/28 12:13:22 | Control event monitor thread =20
started.
INFO   | jvm 1    | 2007/02/28 12:13:22 | Startup runner thread started.
INFO   | jvm 1    | 2007/02/28 12:13:22 | =20
WrapperManager.start(CASMainServiceStarter@8813f2, args[]) called by =20
thread: main
INFO   | jvm 1    | 2007/02/28 12:13:22 | Communications runner thread =20
started.
INFO   | jvm 1    | 2007/02/28 12:13:22 | Open socket to =20
wrapper...Wrapper-Connection
INFO   | jvm 1    | 2007/02/28 12:13:22 | Opened Socket from 31000 to 32000
INFO   | jvm 1    | 2007/02/28 12:13:22 | Send a packet KEY : iZUbwb5BexmgbI=
ru
INFO   | jvm 1    | 2007/02/28 12:13:22 | =20
handleSocket(Socket[addr=3D/127.0.0.1,port=3D32000,localport=3D31000])
DEBUG  | wrapperp | 2007/02/28 12:13:22 | accepted a socket from =20
127.0.0.1 on port 31000
DEBUG  | wrapperp | 2007/02/28 12:13:22 | read a packet KEY : iZUbwb5BexmgbI=
ru
DEBUG  | wrapper  | 2007/02/28 12:13:22 | Got key from JVM: iZUbwb5BexmgbIru
DEBUG  | wrapperp | 2007/02/28 12:13:22 | send a packet LOW_LOG_LEVEL : 1
DEBUG  | wrapperp | 2007/02/28 12:13:22 | send a packet PING_TIMEOUT : 120
DEBUG  | wrapperp | 2007/02/28 12:13:22 | send a packet PROPERTIES : =20
(Property Values)
DEBUG  | wrapper  | 2007/02/28 12:13:22 | Start Application.
DEBUG  | wrapperp | 2007/02/28 12:13:22 | send a packet START : start
INFO   | jvm 1    | 2007/02/28 12:13:23 | Received a packet LOW_LOG_LEVEL : =
1
INFO   | jvm 1    | 2007/02/28 12:13:23 | Wrapper Manager: LowLogLevel =20
from Wrapper is 1
INFO   | jvm 1    | 2007/02/28 12:13:23 | Received a packet PING_TIMEOUT : 1=
20
INFO   | jvm 1    | 2007/02/28 12:13:23 | PingTimeout from Wrapper is 120000
INFO   | jvm 1    | 2007/02/28 12:13:23 | Received a packet PROPERTIES =20
: (Property Values)
INFO   | jvm 1    | 2007/02/28 12:13:23 | Received a packet START : start
INFO   | jvm 1    | 2007/02/28 12:13:23 | calling WrapperListener.start()
INFO   | jvm 1    | 2007/02/28 12:13:23 | Waiting for =20
WrapperListener.start runner thread to complete.
INFO   | jvm 1    | 2007/02/28 12:13:23 | WrapperListener.start runner =20
thread started.
INFO   | jvm 1    | 2007/02/28 12:13:23 | Send a packet START_PENDING : 1000=
0
INFO   | jvm 1    | 2007/02/28 12:13:23 | Starting CASMain!
INFO   | jvm 1    | 2007/02/28 12:13:23 | WrapperListener.start runner =20
thread stopped.
INFO   | jvm 1    | 2007/02/28 12:13:23 | returned from =20
WrapperListener.start()
INFO   | jvm 1    | 2007/02/28 12:13:23 | Send a packet STARTED :
DEBUG  | wrapperp | 2007/02/28 12:13:23 | read a packet START_PENDING : 1000=
0
DEBUG  | wrapper  | 2007/02/28 12:13:23 | JVM signalled a start =20
pending with waitHint of 10000 millis.
DEBUG  | wrapperp | 2007/02/28 12:13:23 | read a packet STARTED :
DEBUG  | wrapper  | 2007/02/28 12:13:23 | JVM signalled that it was started.
INFO   | jvm 1    | 2007/02/28 12:13:23 | Startup runner thread stopped.
INFO   | jvm 1    | 2007/02/28 12:13:24 | Wrapper Manager: =20
ShutdownHook started
INFO   | jvm 1    | 2007/02/28 12:13:24 | WrapperManager.stop(0) =20
called by thread: Wrapper-Shutdown-Hook
INFO   | jvm 1    | 2007/02/28 12:13:24 | Send a packet STOP : 0
DEBUG  | wrapperp | 2007/02/28 12:13:24 | read a packet STOP : 0
DEBUG  | wrapper  | 2007/02/28 12:13:24 | JVM requested a shutdown. (0)
DEBUG  | wrapper  | 2007/02/28 12:13:24 | wrapperStopProcess(0) called.
DEBUG  | wrapper  | 2007/02/28 12:13:24 | Sending stop signal to JVM
DEBUG  | wrapperp | 2007/02/28 12:13:24 | send a packet STOP : NULL
INFO   | jvm 1    | 2007/02/28 12:13:24 | Received a packet STOP :
INFO   | jvm 1    | 2007/02/28 12:13:25 | Thread, =20
Wrapper-Shutdown-Hook, handling the shutdown process.
INFO   | jvm 1    | 2007/02/28 12:13:25 | calling listener.stop()
INFO   | jvm 1    | 2007/02/28 12:13:25 | Send a packet STOP_PENDING : 10000
DEBUG  | wrapperp | 2007/02/28 12:13:25 | read a packet STOP_PENDING : 10000
DEBUG  | wrapper  | 2007/02/28 12:13:25 | JVM signalled a stop pending =20
with waitHint of 10000 millis.
ERROR  | wrapper  | 2007/02/28 12:13:35 | Shutdown failed: Timed out =20
waiting for signal from JVM.
ERROR  | wrapper  | 2007/02/28 12:13:35 | JVM did not exit on request, =20
terminated
DEBUG  | wrapperp | 2007/02/28 12:13:35 | server listening on port 32000.
STATUS | wrapper  | 2007/02/28 12:13:35 | <-- Wrapper Stopped

----- End of JRE 1.5.0 Log -----




---- Wrapper Log with JRE 1.4.2 -----
STATUS | wrapper  | 2007/02/28 12:14:26 | --> Wrapper Started as Console
DEBUG  | wrapper  | 2007/02/28 12:14:26 | Using tick timer.
DEBUG  | wrapperp | 2007/02/28 12:14:26 | server listening on port 32000.
STATUS | wrapper  | 2007/02/28 12:14:26 | Launching a JVM...
DEBUG  | wrapper  | 2007/02/28 12:14:26 | command: "C:\Program =20
Files\Java\j2re1.4.2_11\bin\java" -Xms32m -Xmx128m =20
-Djava.library.path=3D"." -classpath =20
"./wrapper.jar;./css.jar;.;./all.jar;./mail.jar;./activation.jar" =20
-Dwrapper.key=3D"GYu8PqqjL8ZrHwiM" -Dwrapper.port=3D32000 =20
-Dwrapper.jvm.port.min=3D31000 -Dwrapper.jvm.port.max=3D31999 =20
-Dwrapper.debug=3D"TRUE" -Dwrapper.pid=3D5236 -Dwrapper.version=3D"3.2.3" =
=20
-Dwrapper.native_library=3D"wrapper" -Dwrapper.cpu.timeout=3D"10" =20
-Dwrapper.jvmid=3D1 CASMainServiceStarter
DEBUG  | wrapper  | 2007/02/28 12:14:26 | JVM started (PID=3D3164)
INFO   | jvm 1    | 2007/02/28 12:14:27 | WrapperManager class =20
initialized by thread: main  Using classloader: =20
sun.misc.Launcher$AppClassLoader@53ba3d
INFO   | jvm 1    | 2007/02/28 12:14:27 | Wrapper (Version 3.2.3) =20
http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2007/02/28 12:14:27 |   Copyright 1999-2006 Tanuki =20
Software, Inc.  All Rights Reserved.
INFO   | jvm 1    | 2007/02/28 12:14:27 |
INFO   | jvm 1    | 2007/02/28 12:14:27 | Wrapper Manager: JVM #1
INFO   | jvm 1    | 2007/02/28 12:14:27 | Running a 32-bit JVM.
INFO   | jvm 1    | 2007/02/28 12:14:27 | Wrapper Manager: Registering =20
shutdown hook
INFO   | jvm 1    | 2007/02/28 12:14:27 | Wrapper Manager: Using wrapper
INFO   | jvm 1    | 2007/02/28 12:14:27 | Load native library.  One or =20
more attempts may fail if platform specific libraries do not exist.
INFO   | jvm 1    | 2007/02/28 12:14:27 | Loading native library =20
failed: wrapper-windows-x86-32.dll  Cause: =20
java.lang.UnsatisfiedLinkError: no wrapper-windows-x86-32 in =20
java.library.path
INFO   | jvm 1    | 2007/02/28 12:14:27 | Loaded native library: wrapper.dll
INFO   | jvm 1    | 2007/02/28 12:14:27 | Calling native =20
initialization method.
INFO   | jvm 1    | 2007/02/28 12:14:27 | Initializing WrapperManager =20
native library.
INFO   | jvm 1    | 2007/02/28 12:14:27 | Java Executable: C:\Program =20
Files\Java\j2re1.4.2_11\bin\java.exe
INFO   | jvm 1    | 2007/02/28 12:14:27 | Windows version: 5.2.3790
INFO   | jvm 1    | 2007/02/28 12:14:27 | Java Version   : =20
1.4.2_11-b06 Java HotSpot(TM) Client VM
INFO   | jvm 1    | 2007/02/28 12:14:27 | Java VM Vendor : Sun =20
Microsystems Inc.
INFO   | jvm 1    | 2007/02/28 12:14:27 |
INFO   | jvm 1    | 2007/02/28 12:14:27 | Control event monitor thread =20
started.
INFO   | jvm 1    | 2007/02/28 12:14:27 | Startup runner thread started.
INFO   | jvm 1    | 2007/02/28 12:14:27 | =20
WrapperManager.start(CASMainServiceStarter@1d99a4d, args[]) called by =20
thread: main
INFO   | jvm 1    | 2007/02/28 12:14:27 | Communications runner thread =20
started.
INFO   | jvm 1    | 2007/02/28 12:14:27 | Open socket to =20
wrapper...Wrapper-Connection
INFO   | jvm 1    | 2007/02/28 12:14:27 | Opened Socket from 31000 to 32000
INFO   | jvm 1    | 2007/02/28 12:14:27 | Send a packet KEY : GYu8PqqjL8ZrHw=
iM
INFO   | jvm 1    | 2007/02/28 12:14:27 | =20
handleSocket(Socket[addr=3D/127.0.0.1,port=3D32000,localport=3D31000])
DEBUG  | wrapperp | 2007/02/28 12:14:27 | accepted a socket from =20
127.0.0.1 on port 31000
DEBUG  | wrapperp | 2007/02/28 12:14:27 | read a packet KEY : GYu8PqqjL8ZrHw=
iM
DEBUG  | wrapper  | 2007/02/28 12:14:27 | Got key from JVM: GYu8PqqjL8ZrHwiM
DEBUG  | wrapperp | 2007/02/28 12:14:27 | send a packet LOW_LOG_LEVEL : 1
DEBUG  | wrapperp | 2007/02/28 12:14:27 | send a packet PING_TIMEOUT : 120
DEBUG  | wrapperp | 2007/02/28 12:14:27 | send a packet PROPERTIES : =20
(Property Values)
DEBUG  | wrapper  | 2007/02/28 12:14:27 | Start Application.
DEBUG  | wrapperp | 2007/02/28 12:14:27 | send a packet START : start
INFO   | jvm 1    | 2007/02/28 12:14:27 | Received a packet LOW_LOG_LEVEL : =
1
INFO   | jvm 1    | 2007/02/28 12:14:27 | Wrapper Manager: LowLogLevel =20
from Wrapper is 1
INFO   | jvm 1    | 2007/02/28 12:14:27 | Received a packet PING_TIMEOUT : 1=
20
INFO   | jvm 1    | 2007/02/28 12:14:27 | PingTimeout from Wrapper is 120000
INFO   | jvm 1    | 2007/02/28 12:14:27 | Received a packet PROPERTIES =20
: (Property Values)
INFO   | jvm 1    | 2007/02/28 12:14:27 | Received a packet START : start
INFO   | jvm 1    | 2007/02/28 12:14:27 | calling WrapperListener.start()
INFO   | jvm 1    | 2007/02/28 12:14:27 | Waiting for =20
WrapperListener.start runner thread to complete.
INFO   | jvm 1    | 2007/02/28 12:14:27 | WrapperListener.start runner =20
thread started.
INFO   | jvm 1    | 2007/02/28 12:14:27 | Send a packet START_PENDING : 1000=
0
INFO   | jvm 1    | 2007/02/28 12:14:27 | Starting CASMain!
INFO   | jvm 1    | 2007/02/28 12:14:27 | WrapperListener.start runner =20
thread stopped.
INFO   | jvm 1    | 2007/02/28 12:14:27 | returned from =20
WrapperListener.start()
INFO   | jvm 1    | 2007/02/28 12:14:27 | Send a packet STARTED :
INFO   | jvm 1    | 2007/02/28 12:14:27 | Startup runner thread stopped.
DEBUG  | wrapperp | 2007/02/28 12:14:27 | read a packet START_PENDING : 1000=
0
DEBUG  | wrapper  | 2007/02/28 12:14:27 | JVM signalled a start =20
pending with waitHint of 10000 millis.
DEBUG  | wrapperp | 2007/02/28 12:14:27 | read a packet STARTED :
DEBUG  | wrapper  | 2007/02/28 12:14:27 | JVM signalled that it was started.
DEBUG  | wrapperp | 2007/02/28 12:14:31 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:31 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:31 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:31 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:31 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:14:35 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:36 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:36 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:36 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:36 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:14:40 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:40 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:40 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:40 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:40 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:14:44 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:44 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:44 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:44 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:44 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:14:49 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:49 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:49 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:49 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:49 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:14:53 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:53 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:53 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:53 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:53 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:14:58 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:58 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:14:58 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:14:58 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:14:58 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:15:02 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:15:02 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:15:02 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:15:02 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:15:02 | Got ping response from JVM
DEBUG  | wrapperp | 2007/02/28 12:15:07 | send a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:15:07 | Received a packet PING : ping
INFO   | jvm 1    | 2007/02/28 12:15:07 | Send a packet PING : ok
DEBUG  | wrapperp | 2007/02/28 12:15:07 | read a packet PING : ok
DEBUG  | wrapper  | 2007/02/28 12:15:07 | Got ping response from JVM
STATUS | wrapper  | 2007/02/28 12:15:07 | CTRL-C trapped.  Shutting down.
DEBUG  | wrapper  | 2007/02/28 12:15:07 | wrapperStopProcess(0) called.
INFO   | jvm 1    | 2007/02/28 12:15:07 | Got Control Signal 0->200
INFO   | jvm 1    | 2007/02/28 12:15:07 | Handled signal
INFO   | jvm 1    | 2007/02/28 12:15:07 | Processing control =20
event(WRAPPER_CTRL_C_EVENT)
DEBUG  | wrapper  | 2007/02/28 12:15:07 | Sending stop signal to JVM
DEBUG  | wrapperp | 2007/02/28 12:15:07 | send a packet STOP : NULL
INFO   | jvm 1    | 2007/02/28 12:15:08 | Received a packet STOP :
INFO   | jvm 1    | 2007/02/28 12:15:08 | Thread, Wrapper-Connection, =20
handling the shutdown process.
INFO   | jvm 1    | 2007/02/28 12:15:08 | calling listener.stop()
INFO   | jvm 1    | 2007/02/28 12:15:08 | Waiting for =20
WrapperListener.stop runner thread to complete.
INFO   | jvm 1    | 2007/02/28 12:15:08 | WrapperListener.stop runner =20
thread started.
INFO   | jvm 1    | 2007/02/28 12:15:08 | Send a packet STOP_PENDING : 10000
DEBUG  | wrapperp | 2007/02/28 12:15:08 | read a packet STOP_PENDING : 10000
DEBUG  | wrapper  | 2007/02/28 12:15:08 | JVM signalled a stop pending =20
with waitHint of 10000 millis.
INFO   | jvm 1    | 2007/02/28 12:15:14 | Wrapper Manager: =20
ShutdownHook started
INFO   | jvm 1    | 2007/02/28 12:15:14 | WrapperManager.stop(0) =20
called by thread: Wrapper-Shutdown-Hook
INFO   | jvm 1    | 2007/02/28 12:15:14 | Thread, =20
Wrapper-Shutdown-Hook, waiting for the JVM to exit.
INFO   | jvm 1    | 2007/02/28 12:15:14 | System.exit appears to have =20
been called from within the
INFO   | jvm 1    | 2007/02/28 12:15:14 |   WrapperListener.stop() =20
method.  If possible the application
INFO   | jvm 1    | 2007/02/28 12:15:14 |   should be modified to =20
avoid this behavior.
INFO   | jvm 1    | 2007/02/28 12:15:14 |   To avoid a deadlock, this =20
thread will only wait 5 seconds
INFO   | jvm 1    | 2007/02/28 12:15:14 |   for the application to =20
shutdown.  This may result in the
INFO   | jvm 1    | 2007/02/28 12:15:14 |   application failing to =20
shutdown completely before the JVM
INFO   | jvm 1    | 2007/02/28 12:15:14 |   exists.  Removing the =20
offending System.exit call will
INFO   | jvm 1    | 2007/02/28 12:15:14 |   resolve this.
INFO   | jvm 1    | 2007/02/28 12:15:16 | WrapperListener.stop runner =20
thread stopped.
INFO   | jvm 1    | 2007/02/28 12:15:16 | returned from listener.stop() -> 0
INFO   | jvm 1    | 2007/02/28 12:15:16 | shutdownJVM(0) =20
Thread:Wrapper-Connection
INFO   | jvm 1    | 2007/02/28 12:15:16 | Send a packet STOPPED : 0
DEBUG  | wrapperp | 2007/02/28 12:15:16 | read a packet STOPPED : 0
DEBUG  | wrapper  | 2007/02/28 12:15:16 | JVM signalled that it was stopped.
INFO   | jvm 1    | 2007/02/28 12:15:16 | Closing socket.
DEBUG  | wrapperp | 2007/02/28 12:15:16 | socket read no code (closed?).
DEBUG  | wrapperp | 2007/02/28 12:15:16 | server listening on port 32001.
INFO   | jvm 1    | 2007/02/28 12:15:16 | calling System.exit(0)
INFO   | jvm 1    | 2007/02/28 12:15:16 | Send a packet STOPPED : 0
INFO   | jvm 1    | 2007/02/28 12:15:17 | Wrapper Manager: =20
ShutdownHook complete
DEBUG  | wrapper  | 2007/02/28 12:15:17 | JVM process exited with a =20
code of 2, setting the wrapper exit code to 2.
DEBUG  | wrapper  | 2007/02/28 12:15:17 | JVM exited normally.
STATUS | wrapper  | 2007/02/28 12:15:17 | <-- Wrapper Stopped

-------- End of Wrapper.LOG with JRE 1.4.2 -----

Re: [Wrapper-user] Can't stop Daemon process on Mac

[Mark L. <mid...@ve...>]

Leif Mortenson wrote:
> Mark,
> There is a bug in the sh script for OSX.  Please download the latest 
> script here:
> http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in 
>
>
Thanks! Works perfectly.

-Mark

Re: [Wrapper-user] Can't stop Daemon process on Mac

[Leif M. <le...@ta...>]

Mark,
There is a bug in the sh script for OSX.  Please download the latest 
script here:
http://wrapper.svn.sourceforge.net/viewvc/*checkout*/wrapper/trunk/wrapper/src/bin/sh.script.in

This will be fixed in the 3.2.4 release.

Cheers,
Lei

Mark Leone wrote:
> On Mac OS 10.4.8 with Wrapper_3.2.3, I launch my app as a daemon by 
> typing "./RCBServer start", and it starts up properly. However, when I 
> try to stop it via "./RCBServer stop" I get unexpected behavior. I get 
> an error message on the command line saying that the daemon wasn't 
> running, but in fact it continues to run indefinitely. I know it's 
> running because it's listening for TCP connections on a high port, and 
> I'm able to connect to it. I can also see the connection established via 
> netstat. The only way I can stop the daemon is to kill the process named 
> wrapper.
>
> Here's what I get when I try to stop the daemon when it's running. It 
> looks like it's having trouble with the pid file. I left the PIDDIR set 
> to "." in wrapper.conf.  After starting the daemon I see the pid file in 
> RCB Server/bin, and it has the pid of the process named wrapper.
>
> mac_mini:/Applications/Remote Clipboard/bin <username>$ ./RCBServer stop
> Stopping RCBServer...
> ps: args: keyword not found
> ps: no valid keywords
> Removed stale pid file: /Applications/Remote Clipboard/bin/./RCBServer.pid
> RCBServer was not running.
> mac_mini:/Applications/Remote Clipboard/bin <username>$
>   

[Wrapper-user] Can't stop Daemon process on Mac

[Mark L. <mid...@ve...>]

On Mac OS 10.4.8 with Wrapper_3.2.3, I launch my app as a daemon by 
typing "./RCBServer start", and it starts up properly. However, when I 
try to stop it via "./RCBServer stop" I get unexpected behavior. I get 
an error message on the command line saying that the daemon wasn't 
running, but in fact it continues to run indefinitely. I know it's 
running because it's listening for TCP connections on a high port, and 
I'm able to connect to it. I can also see the connection established via 
netstat. The only way I can stop the daemon is to kill the process named 
wrapper.

Here's what I get when I try to stop the daemon when it's running. It 
looks like it's having trouble with the pid file. I left the PIDDIR set 
to "." in wrapper.conf.  After starting the daemon I see the pid file in 
RCB Server/bin, and it has the pid of the process named wrapper.

mac_mini:/Applications/Remote Clipboard/bin <username>$ ./RCBServer stop
Stopping RCBServer...
ps: args: keyword not found
ps: no valid keywords
Removed stale pid file: /Applications/Remote Clipboard/bin/./RCBServer.pid
RCBServer was not running.
mac_mini:/Applications/Remote Clipboard/bin <username>$

Re: [Wrapper-user] Shell script won't execute on Mac

[Mark L. <mid...@ve...>]

Leif Mortenson wrote:
> Mark,
> Hmm, the most common problem are line feeds, but it sounds like you 
> have checked
> that.
Found the problem. It was a combination of two things. I needed to use 
./RCBServer as suggested by a couple people, and TextWrangler apparently 
failed to save the file properly even when I selected Unix line breaks. 
I saved it with TextEdit and it worked. Thanks for the help. I have an 
additional problem now but I'll post that in another thread.

-Mark

Re: [Wrapper-user] Shell script won't execute on Mac

[Leif M. <le...@ta...>]

Mark,
Hmm, the most common problem are line feeds, but it sounds like you have 
checked
that.

What version of the Wrapper are you using?  Is the shell script from the 
same version.
Newer versions of the shell script should handle this better, but have 
you made sure that
the wrapper binary exists, is the correct version for the platform, and 
has its executable
bit set?

When all else fails, try adding the following towards the top of the 
shell script.
---
echo "Here"
---
Try rerunning it.  If you see the message, then we know that the script 
is being run
and that is a problem with something in the script.   If not then we 
know that is something
wrong with the script that is severe enough that the script can't be run 
at all.

If it is something in the script, try adding more echo statements to 
track down the
culprit and get back to me.  A pain, but that will be the fasted route 
to a solution.

Cheers,
Leif

Mark Leone wrote:
> Chris wrote:
>   
>> Are you sure you don't have to type "./RCBServer" to run a local script?
>> Otherwise (without the "./"), won't it just look in the PATH for the 
>> RCBServer executable?
>>
>> Does the first line in the script point to a real interpreter on your 
>> system? i.e.
>> #!/path/to/sh
>>
>>     
> Thanks for responding. I tried ./RCBServer just now, and still get the 
> "Command not found" response. Also the first line in the script is 
> #!/bin/sh. I do have sh at that location, and when I type "/bin/sh" I 
> get a shell prompt. I verified that the execute bit is set for all three 
> groups on /bin/sh. Also, I have many other scripts that I can run by 
> typing their name. For example I have a Tomcat startup script named 
> Tomcat that I can execute by typing Tomcat from the script directory. It 
> has the same first line as the script that won't execute. The Wrapper 
> script came with a space after !, i.e. #! /bin/sh. My Tomcat script 
> doesn't have this space, i.e. #!/bin/sh, so I tried that also and still 
> get the Command not found error.
>
> If I try to launch the script via double-clicking in the Finder, the 
> system asks me what application I want to use to open that document. But 
> the metadata for the file says that it's a Unix executable file. I don't 
> know if that's normal, or a hint to what is preventing this script from 
> executing.
>
> -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] Shell script won't execute on Mac

[Karthik R. <ka...@ch...>]

Mark, 
I am not a unix expert but I have the wrapper working on Mac OS X. 
Maybe you tried this already but just in case - did you try using
./RCBServer instead of just RCBServer? It could be that the current folder
is not in the path. 

--karthik

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Mark Leone
Sent: Sunday, February 25, 2007 11:36 PM
To: wra...@li...
Subject: [Wrapper-user] Shell script won't execute on Mac

I was able to get Wrapper running on Windows in about 10 minutes, but 3 
hours so far trying to make it work with the Mac have been fruitless. 
The problem is simple. I copied script.sh.in to my app's /bin directory, 
renamed it RCBServer (my app name), set its file mode to 774, edited the 
app name variable settings as directed in the instructions, and made 
sure to save the script file with Unix line breaks. But when I type 
"RCBServer" from the bin directory that contains the script file with 
that name, I get the error message "Command not found."  I can run shell 
scripts anywhere else on my Mac in this fashion, but this one just won't 
run for some reason. I must be missing something really basic, but it's 
obviously not going to occur to me without help.

-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