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

Re: [Wrapper-user] working dir on windows and unix

[<nic...@uk...>]

Thanks Leif.
Sorry for the delay in reply - been busy. And I needed a weekend to
experiment with the live server...

That patch you gave me helped qite a bit.
With a couple of changes :
(I will include my whole script as an attachment - but here are the
itemised changes)

# REALDIR=`pwd`
REALDIR=`dirname "$REALPATH"`
(This avoids symlinking problems)

I added an extra test/modification for WRAPPER_CMD

# Same test for WRAPPER_CMD
FIRST_CHAR=`echo $WRAPPER_CMD | cut -c1,1`
if [ "$FIRST_CHAR" != "/" ]
then
WRAPPER_CMD=$REALDIR/$WRAPPER_CMD
fi

Also, to keep my wrapper.conf the same on windows and linux, I had to add
the following change

# Change the current directory to the location of the script
#cd "`dirname "$REALPATH"`"
cd "`dirname "$WRAPPER_CMD"`"

(and obviously I had to move this line to *after* the relative-dir checks
due to dependancy on $WRAPPER_CMD)


>> "/".  This assumes the
>> root on both platforms.  (Is that really what you want in UNIX??)
Sorry, I mislead you... by {root} I meant root of application rather than
"/root"
{root} means {path-to-app}

>> I am debating modifying the UNIX version of the Wrapper
>> so that it starts with forcing the working directory to the
>> location of the binary as is done on Windows.
You will still need these changes to the scripts.
Perhaps my "cd" change wont be required though....

IMO it would be excellent if the windows and unix platforms behaved the
same.
It would mean we have the same behaviour (and hence the same wrapper.conf)
regardless of target OS.
This is ideal if you are
a) developing on different os than target
b) you want to ship a product that uses wrapper.

>> It would be an incompatibility, but it would clean things up in the
>> long run...
What would the incompatibility be with?
Do you mean break in backward compatibility?

-Nick

(See attached file: Fishy.sh)







Internet
le...@ta...@lists.sourceforge.net - 06/12/2004 09:50


Please respond to wra...@li...

Sent by:    wra...@li...



To:    wrapper-user

cc:


Subject:    Re: [Wrapper-user] working dir on windows and unix


Nick,
    You stumbled onto a bug in the shell script.  The problem is that
the paths to the wrapper
conf and pid files are relative.   The shell script is expecting them to
be relative to the location
of the shell script, and thus home directory.  After changing the
working directory, this is no
longer true.

    I am still working on cleaning this up for the next release.

    I have attached a shell script which will use fully qualified paths
for the locations of the
pid files and config file.   The script assumes that the sh is in the
same directory as the
Wrapper binary.

    In your case you are putting the shell in the root so you will need
to do a little more
work  Change the value of the WRAPPER_CONF and PIDDIR variables in the
script
to appropriate values.

    Then when you launch the Wrapper, rather than placing the
wrapper.working.dir
property in the wrapper.conf, either pass it in as a parameter.
"../../" for Windows
or "." for UNIX.
    Another option is to leave it in the conf file, but use the value
"/".  This assumes the
root on both platforms.  (Is that really what you want in UNIX??)

    I would appreciate your feedback on this and will try to get it
cleaned up for the
next release.  I am debating modifying the UNIX version of the Wrapper
so that
it starts with forcing the working directory to the location of the
binary as is done
on Windows.   It would be an incompatibility, but it would clean things
up in the
long run...

Cheers,
Leif

nic...@uk... wrote:

>Hi,
>
>I am trying to get my app working under windows and linux with the same
>config & behaviour
>
>My dir structure looks like this
>{root}/MyApp.sh
>{root}/MyApp.bat
>{root}/wrapper/bin
>{root}/wrapper/conf
>{root}/wrapper/lib
>
>1) I want my scripts are outside of bin - {root}
>2) I want my running dir is outside of bin  - {root}
>
>I have modified the scripts to find the wrapper(.exe) binary & config from
>where they are.
>I have set the wrapper.working.dir property to ../../ - in order to make
it
>run in the {root} dir.
>On windows my config works fine. If I leave the unmodified scripts in the
>{root}/wrapper/bin everything works fine also.
>
>But on linux, the problem I have is that the wrapper binary doesnt start
in
>./wrapper/bin - and hence ../../ doesnt make sense - and all paths in the
>wrapper.conf are off.
>What I am struggling with is how to modify the script so that it runs the
>wrapper binary in the {root}/wrapper/bin dir rather than the current dir.
>
>Thanks.
>
>-Nick
>
>


#! /bin/sh

#
# Copyright (c) 1999, 2004 Tanuki Software
#
# 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="@app.name@"
APP_LONG_NAME="@app.long.name@"

# 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

# If specified, the Wrapper will be run as the specified user when the
'start'
#  command is passed to this script.  When running with the 'console'
command
#  the current user will be used.
# 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

# Change spaces to ":" so the tokens can be parsed.
SCRIPT=`echo $SCRIPT | sed -e 's; ;:;g'`
# Get the real path to this script, resolving any symbolic links
TOKENS=`echo $SCRIPT | sed -e 's;/; ;g'`
REALPATH=
for C in $TOKENS; do
    REALPATH="$REALPATH/$C"
    while [ -h "$REALPATH" ] ; do
        LS="`ls -ld "$REALPATH"`"
        LINK="`expr "$LS" : '.*-> \(.*\)$'`"
        if expr "$LINK" : '/.*' > /dev/null; then
            REALPATH="$LINK"
        else
            REALPATH="`dirname "$REALPATH"`""/$LINK"
        fi
    done
done
# Change ":" chars back to spaces.
REALPATH=`echo $REALPATH | sed -e 's;:; ;g'`

# 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_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"
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

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

# Check the configured 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

getpid() {
    if [ -f $PIDFILE ]
    then
        if [ -r $PIDFILE ]
        then
            pid=`cat $PIDFILE`
            if [ "X$pid" != "X" ]
            then
                # Verify that a process with this pid is still running.
                pid=`$PSEXE -p $pid | grep $pid | grep -v grep | awk
                '{print $1}' | tail -1`
                if [ "X$pid" = "X" ]
                then
                    # This is a stale pid file.
                    rm -f $PIDFILE
                    echo "Removed stale pid file: $PIDFILE"
                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
    fi
}

console() {
    echo "Running $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        if [ "X$IGNORE_SIGNALS" = "X" ]
        then
            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
        wrapper.pidfile=$PIDFILE
        else
            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
        wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE
        fi
    else
        echo "$APP_LONG_NAME is already running."
        exit 1
    fi
}

start() {
    echo "Starting $APP_LONG_NAME..."
    getpid
    if [ "X$pid" = "X" ]
    then
        if [ "X$IGNORE_SIGNALS" = "X" ]
        then
            if [ "X$RUN_AS_USER" = "X" ]
            then
                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
            wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE
            else
                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD
            $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE"
            fi
        else
            if [ "X$RUN_AS_USER" = "X" ]
            then
                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
            wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE
            wrapper.ignore_signals=TRUE wrapper.daemonize=TRUE
            else
                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD
            $WRAPPER_CONF wrapper.pidfile=$PIDFILE
            wrapper.anchorfile=$ANCHORFILE wrapper.ignore_signals=TRUE
            wrapper.daemonize=TRUE"
            fi
        fi
    else
        echo "$APP_LONG_NAME is already running."
        exit 1
    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
            # Loop for up to 5 minutes
            if [ "$TOTCNT" -lt "300" ]
            then
                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
            else
                pid=
            fi
        done

        pid=$savepid
        testpid
        if [ "X$pid" != "X" ]
        then
            echo "Timed out waiting for $APP_LONG_NAME to exit."
            echo "  Attempting a forced exit..."
            kill -9 $pid
        fi

        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')
        console
        ;;

    'start')
        start
        ;;

    'stop')
        stopit
        ;;

    'restart')
        stopit
        start
        ;;

    'status')
        status
        ;;

    'dump')
        dump
        ;;

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

exit 0


This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.

RE: [Wrapper-user] Service GUI Problem

[Stuijt, J. <JS...@gt...>]

Hi Corey,

I also specify: wrapper.ntservice.hide-console=false
Together with:  wrapper.ntservice.interactive=true

And my JFrame displays well.

Good luck!

Johan


Met vriendelijke groet,
Johan Stuijt
Application Engineer
MES Expert Center
Doorkiesnummer: 075 612 79 34
 
GTI Industrie Noordwest bv
	Industrial Automation

	Houthavenkade 44  1506 PD Zaandam
	Postbus 1377  1500 AJ Zaandam
	tel.: 075 612 76 00   fax: 075 612 30 60
	www.gti-group.com/ia



-----Oorspronkelijk bericht-----
Van: Corey Baswell [mailto:cor...@gm...] 
Verzonden: woensdag 8 december 2004 15:29
Aan: wra...@li...
Onderwerp: [Wrapper-user] Service GUI Problem

I am having trouble displaying a simple JFrame using the wrapper
service.  The environment I'm working in is:

Windows 2000
JRE 1.4
Wrapper Service 3.1.2

The service appears to install and run fine (no error messages in
event log or wrapper.log file).  However the JFrame that is displayed
when running in application mode (via. App.bat) is never displayed
when running as a service.  Using log statements I verified the code
to display the JFrame was executed when running as a service.  I have
the following property set in the config file:

wrapper.ntservice.interactive=true

I tested this on a XP machine and it worked fine (running as service).
 Any ideas on what might be going one or where I might look for hints?

Thanks,
Corey


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.
================================================

[Wrapper-user] Service GUI Problem

[Corey B. <cor...@gm...>]

I am having trouble displaying a simple JFrame using the wrapper
service.  The environment I'm working in is:

Windows 2000
JRE 1.4
Wrapper Service 3.1.2

The service appears to install and run fine (no error messages in
event log or wrapper.log file).  However the JFrame that is displayed
when running in application mode (via. App.bat) is never displayed
when running as a service.  Using log statements I verified the code
to display the JFrame was executed when running as a service.  I have
the following property set in the config file:

wrapper.ntservice.interactive=true

I tested this on a XP machine and it worked fine (running as service).
 Any ideas on what might be going one or where I might look for hints?

Thanks,
Corey

[Wrapper-user] Windows console logoff kills subprocess

[Richard E. <rem...@ed...>]

Not on all our Windows machines, but on some of them, when the
wrapper is started as a service and then the user logs off from
their console session, the Java
process that the wrapper is managing is stopped (with shutdown hook
execution). Then the wrapper notices that the Java process has stopped
and restarts it.

I have argued that it must be some funky Windows setting that does it
but, being the wrapper advocate here, I have been stuck with figuring
out why.

Any help is welcome (and no I can not convince everyone to switch to
Linux).

Richard



-- 
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.

Re: [Wrapper-user] stopping a wrapper process from cmd line

[Cory R. <spa...@gm...>]

I didn't realize that I had emailed it to you directly until it was
too late. I reposted it to the user list after that. Sorry for the
slip-up but thanks for the quick reply. It was exactly what I was
looking for.

Cory


On Wed, 08 Dec 2004 08:53:28 +0900, Leif Mortenson
<le...@ta...> wrote:
> Oops saw the mail you send directly before the one on the list.  See my
> other reply.
> Cheers,
> Leif
> 
> 
> 
> Cory Riddell wrote:
> 
> >I am starting a server with:
> >  wrapper.exe -c CFG_FILE
> >and I'm wondering if there is a similar way to stop the wrapped
> >process? This is often running from a USB thumbdrive, so I don't want
> >to install it as a service, but I need to be able to stop it from a
> >batch file. I'm looking for something like:
> >  wrapper.exe -halt CFG_FILE
> >
> >Any suggestions?
> >
> >Cory
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://productguide.itmanagersjournal.com/
> >_______________________________________________
> >Wrapper-user mailing list
> >Wra...@li...
> >https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
> >
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] stopping a wrapper process from cmd line

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

Oops saw the mail you send directly before the one on the list.  See my 
other reply.
Cheers,
Leif

Cory Riddell wrote:

>I am starting a server with:
>  wrapper.exe -c CFG_FILE
>and I'm wondering if there is a similar way to stop the wrapped
>process? This is often running from a USB thumbdrive, so I don't want
>to install it as a service, but I need to be able to stop it from a
>batch file. I'm looking for something like:
>  wrapper.exe -halt CFG_FILE
>
>Any suggestions?
>
>Cory
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

[Wrapper-user] Re: stopping a wrapper process from cmd line

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

Cory,
    Please post Wrapper related requests to the Wrapper user mailing 
list rather than sending
them to me directly.

Cory Riddell wrote:

>I am starting a server with: 
>  wrapper.exe -c CFG_FILE 
>and I'm wondering if there is a similar way to stop the wrapped
>process? This is often running from a USB thumbdrive, so I don't want
>to install it as a service, but I need to be able to stop it from a
>batch file. I'm looking for something like:
>  wrapper.exe -halt CFG_FILE
>
>Any suggestions?
>  
>
    When the Wrapper is launched as a console application.   The 
thinking was that it could
be easily stopped by pressing control C or something.   There are not 
any commands which
can be used to stop it as is possible with a service.

    One way that you should be able to do this however is to make use of 
the anchor file
feature added in 3.1.1.   See the docs for wrapper.anchorfile.
http://wrapper.tanukisoftware.org/doc/english/prop-anchorfile.html
   It will create an anchor file at the specified location when the 
wrapper is launched.
The Wrapper will then shut itself down within a few seconds of that file 
being deleted.
   You could then write a simple batch file that deletes this anchor 
file to get the effect
you are looking for.

Cheers,
Leif

[Wrapper-user] GUI Problem

[Corey B. <cor...@ho...>]

<html><div style='background-color:'><DIV class=RTE>I have a problem running a service that displays a simple JFrame.&nbsp; I have installed the service and can start it fine (or atleast it appears). There are no error messages in the wrapper.log file. I am writting to a log file before and after I iniitialize and display the JFrame and&nbsp;the service gets&nbsp;past this point, however the JFrame is never displayed. The service is running on Windows 2000. I have installed and ran the service on Windows XP and it works correctly.&nbsp; When I run the application using the App.bat script on the Windows 2000 server it works correctly.</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>I have the interactive property set as:</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>wrapper.ntservice.interactive=true</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>Does anyone know what I might be happening? I am using the 1.4 JRE.</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>Thanks,</DIV>
<DIV class=RTE>Corey</DIV></div></html>

RE: [Wrapper-user] Re-read wrapper.conf on restart?

[Todd K. <tod...@ac...>]

Thanks Leif!

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...]=20
Sent: Sunday, December 05, 2004 11:11 PM
To: wra...@li...
Subject: Re: [Wrapper-user] Re-read wrapper.conf on restart?

Todd,
I went in today and got this implemented for the the next Wrapper
release (3.2.0).
It will be enabled using a new wrapper.restart.reload_configuration
property.

The patch submitted by Ori will work for most cases. The exception is if
you have
declared any filters or have any dependent services defined on Windows
versions.
Those will both leak memory on each restart but the leak is pretty
small. Everything
else should work for you.
This patch will also have problems if you remove properties from the
configuration
file. You can change or add property values but this patch will not
remove them.

The implementation in the 3.2.0 release is done a bit differently so the
above
problems are all resolved there.

Thanks Ori.

Cheers,
Leif

Ori Argov wrote:

> Hi Todd,
>
> I'm using version 3.0.2 and I also needed this feature (I should
> really upgrade though...).
>
> What I did was add a line to the following function in wrapper.c:
>
> void wrapperRestartRequested() {
>
> log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_STATUS, "JVM requested a
> restart.");
>
> *// THE FOLLOWING LINE WAS ADDED*
>
> *loadProperties(properties, wrapperData->configFile);*
>
> wrapperLoadConfiguration();
>
> wrapperRestartProcess();
>
> }
>
> Then, calling a WrapperManager.restart() will also re-read the
> properties file.
>
> I also found it useful to use the #include feature of the conf files
> in this case and add dynamic classpath
>
> Entries to another conf file which is always included by the main one.
>
> Hope it helps,
>
> Ori
>
>
------------------------------------------------------------------------
>
> *From:* wra...@li...
> [mailto:wra...@li...] *On Behalf Of *Todd
> Klaus
> *Sent:* Saturday, December 04, 2004 4:30 AM
> *To:* wra...@li...
> *Subject:* [Wrapper-user] Re-read wrapper.conf on restart?
>
> Hi,
>
> I am using Wrapper 3.0.5 and have the following classpath set in
> wrapper.conf:
>
> wrapper.java.classpath.1=3D../lib/*.jar
>
> wrapper.java.classpath.2=3D../lib/*.zip
>
> I would like to support upgrade capability in my application whereby
> new jars are sent to the application via JMS and written to the
> applications lib directory (referenced by the classpath above). As
> soon as the new jars are downloaded, I restart the app using
> WrapperManager.restart(). Unfortunately, it seems that the wrapper
> does not rebuild the classpath on restart, because I get ClassNotFound
> exceptions for classes referenced in the new jars after the restart. A
> complete shutdown and restart of the app works fine (but doesn't meet
> the goal of being fully automatic!). These are usually new third-party
> jars, so they were not in the classpath before the upgrade.
>
> I even tried programmatically modifying wrapper.conf to explicity add
> a reference to the new jar, like this:
>
> wrapper.java.classpath.3=3D../lib/newjar.zip
>
> but it seems that the wrapper doesn't even re-read wrapper.conf on a
> restart.
>
> Is there any way to force the wrapper to re-read the conf file? Any
> other way to accomplish this? Any comments/suggestions welcome!
>
> Thanks,
>
> Todd
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.=20
http://productguide.itmanagersjournal.com/
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] stopping a wrapper process from cmd line

[Cory R. <spa...@gm...>]

I am starting a server with:
  wrapper.exe -c CFG_FILE
and I'm wondering if there is a similar way to stop the wrapped
process? This is often running from a USB thumbdrive, so I don't want
to install it as a service, but I need to be able to stop it from a
batch file. I'm looking for something like:
  wrapper.exe -halt CFG_FILE

Any suggestions?

Cory

Re: [SPAM] - Re: [SPAM] - Re: [Wrapper-user] PIDFILE + wrapper.working.dir - Bayesian Filter detected spam - Found word(s) list error remove in the Text body.

[<nic...@uk...>]

you probably need to dos2unix the file....
-Nick




Internet
ste...@ce...@lists.sourceforge.net - 06/12/2004 15:40


Please respond to wra...@li...

Sent by:    wra...@li...



To:    wrapper-user

cc:


Subject:    Re: [SPAM] - Re: [SPAM] - Re: [Wrapper-user] PIDFILE +
       wrapper.working.dir - Bayesian Filter detected spam - Found word(s)
       list error remove  in the Text body.


Leif ,
Sorry for all those posts but when i try to launch the daemon with your
new script
the shell complain about : "bad interpreter ........."
So i can't test it , i'm waiting to see what you think about my last post

Big thanks

St=E9phane RIFF wrote:

> Leif ,
>
> I don't understand your last post: if the shell script use path like :
> PIDDIR : /usr/local/myapp/
> (This is what i've done to make my wrapper work), if you change the
> location or OS you have to change
> your script variables. Or i make a directory tree that can be move
> anywhere with relative path...
>
> Maybe i misunderstound so i gonna try your script to see what happen.
>
> Thanks for your answers
> Bye
>
>
>
> Leif Mortenson wrote:
>
>> Stephane,
>>    Ok, this was a bug in the shell script.   The pid file is created
>> after the working dir is
>> changed but that is not taken into account by the shell script.
>>
>>    I have fixed this for the next release.  The shell script will now
>> always use fully qualified
>> paths to avoid this issue.   I have attached the new shell script.
>> It should work for old
>> versions of the Wrapper.
>>
>>    Let me know how it works for you.
>>
>> Cheers,
>> Leif
>>
>> St=E9phane RIFF wrote:
>>
>>> The user is the same (sure).
>>>
>>> The directory tree is :
>>>       serviceroot
>>>        |
>>>        ---bin
>>>        |      |
>>>        |      ---wrapper
>>>        |      |
>>>        |      ---sh.script
>>>        |
>>>        ---conf
>>>        |     |
>>>        |     ---wrapper.conf
>>>        |
>>>        ---lib
>>>        |
>>>        ---logs
>>>
>>> In the wrapper.conf : wrapper.working.dir=3D"../"
>>> In sh.script : PIDDIR=3D"."
>>>
>>> When i start the service (with user "steff"), the MYAPP.pid file is
>>> in the "serviceroot" directory.
>>> When i want to stop (with user "steff"), the sh.script complains
>>> that "service not running". but
>>> if i print $PIDFILE in the sh.script, it display : "./MYAPP.pid" :
>>> seems good if the working directory
>>> is really set to "serviceroot"
>>>
>>> Maybe i missunderstood about working dir but if someone can points
>>> me to the right solution.....
>>> Thanks to answerers
>>>
>>> Leif Mortenson wrote:
>>>
>>>> Stephane,
>>>>    My first guess here is a permission problem.   Are you starting
>>>> the wrapper as the same
>>>> user that you are later attempting stop it with?   I may have some
>>>> problems there but I have
>>>> not heard of any to date.  Give me a little more info and I'll go
>>>> back and look over the
>>>> script some more.
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> St=E9phane RIFF wrote:
>>>>
>>>>> I have problem with the pid file :
>>>>>   in sh.script.in i have PIDDIR=3D".", the 'start ' command seems to
>>>>> place pidfile in the right location.
>>>>> but when i try to launch a 'stop' command the script tell me that
>>>>> the daemon isn't running .
>>>>>
>>>>> I also echo some variable and the $PIDFILE is : "./MYAPPNAME.pid" so
>>>>> i don't understand why the line : "if [ -f $PIDFILE ]" is not true
>>>>>
>>>>> I don't know if i'm understandable but i suspect there a problem
>>>>> with the sh.script.in and the wrapper.working.dir.
>>>>>
>>>>> any hints are welcome
>>>>> Thanks
>>>>
>>>>
>>>>
>>
>> ------------------------------------------------------------------------
>>
>> #! /bin/sh
>>
>> #
>> # Copyright (c) 1999, 2004 Tanuki Software
>> #
>> # 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=3D"@app.name@"
>> APP_LONG_NAME=3D"@app.long.name@"
>>
>> # Wrapper
>> WRAPPER_CMD=3D"./wrapper"
>> WRAPPER_CONF=3D"../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=3D
>>
>> # Location of the pid file.
>> PIDDIR=3D"."
>>
>> # 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=3Dtrue
>>
>> # If specified, the Wrapper will be run as the specified user when
>> the 'start'
>> #  command is passed to this script.  When running with the 'console'
>> command
>> #  the current user will be used.
>> # 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=3D
>>
>> # 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=3D"$0"
>>        ;;
>>    *)
>>        PWD=3D`pwd`
>>        SCRIPT=3D"$PWD/$0"
>>        ;;
>> esac
>>
>> # Change spaces to ":" so the tokens can be parsed.
>> SCRIPT=3D`echo $SCRIPT | sed -e 's; ;:;g'`
>> # Get the real path to this script, resolving any symbolic links
>> TOKENS=3D`echo $SCRIPT | sed -e 's;/; ;g'`
>> REALPATH=3D
>> for C in $TOKENS; do
>>    REALPATH=3D"$REALPATH/$C"
>>    while [ -h "$REALPATH" ] ; do
>>        LS=3D"`ls -ld "$REALPATH"`"
>>        LINK=3D"`expr "$LS" : '.*-> \(.*\)$'`"
>>        if expr "$LINK" : '/.*' > /dev/null; then
>>            REALPATH=3D"$LINK"
>>        else
>>            REALPATH=3D"`dirname "$REALPATH"`""/$LINK"
>>        fi
>>    done
>> done
>> # Change ":" chars back to spaces.
>> REALPATH=3D`echo $REALPATH | sed -e 's;:; ;g'`
>>
>> # Change the current directory to the location of the script
>> cd "`dirname "$REALPATH"`"
>> REALDIR=3D`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=3D`echo $PIDDIR | cut -c1,1`
>> if [ "$FIRST_CHAR" !=3D "/" ]
>> then
>>        PIDDIR=3D$REALDIR/$PIDDIR
>> fi
>> # Same test for WRAPPER_CONF
>> FIRST_CHAR=3D`echo $WRAPPER_CONF | cut -c1,1`
>> if [ "$FIRST_CHAR" !=3D "/" ]
>> then
>>        WRAPPER_CONF=3D$REALDIR/$WRAPPER_CONF
>> fi
>>
>> # Process ID
>> ANCHORFILE=3D"$PIDDIR/$APP_NAME.anchor"
>> PIDFILE=3D"$PIDDIR/$APP_NAME.pid"
>> pid=3D""
>>
>> # Resolve the location of the 'ps' command
>> PSEXE=3D"/usr/bin/ps"
>> if [ ! -x $PSEXE ]
>> then
>>    PSEXE=3D"/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
>>
>> # Build the nice clause
>> if [ "X$PRIORITY" =3D "X" ]
>> then
>>    CMDNICE=3D""
>> else
>>    CMDNICE=3D"nice -$PRIORITY"
>> fi
>>
>> # Check the configured user
>> if [ "X$RUN_AS_USER" !=3D "X" ]
>> then
>>    # Resolve the location of the 'id' command
>>    IDEXE=3D"/usr/xpg4/bin/id"
>>    if [ ! -x $IDEXE ]
>>    then
>>        IDEXE=3D"/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`" =3D "$RUN_AS_USER" ]
>>    then
>>        # Already running as the configured user.  Avoid password
>> prompts by not calling su.
>>        RUN_AS_USER=3D""
>>    fi
>> fi
>>
>> getpid() {
>>    if [ -f $PIDFILE ]
>>    then
>>        if [ -r $PIDFILE ]
>>        then
>>            pid=3D`cat $PIDFILE`
>>            if [ "X$pid" !=3D "X" ]
>>            then
>>                # Verify that a process with this pid is still running.
>>                pid=3D`$PSEXE -p $pid | grep $pid | grep -v grep | awk
>> '{print $1}' | tail -1`
>>                if [ "X$pid" =3D "X" ]
>>                then
>>                    # This is a stale pid file.
>>                    rm -f $PIDFILE
>>                    echo "Removed stale pid file: $PIDFILE"
>>                fi
>>            fi
>>        else
>>            echo "Cannot read $PIDFILE."
>>            exit 1
>>        fi
>>    fi
>> }
>>
>> testpid() {
>>    pid=3D`$PSEXE -p $pid | grep $pid | grep -v grep | awk '{print $1}'
>> | tail -1`
>>    if [ "X$pid" =3D "X" ]
>>    then
>>        # Process is gone so remove the pid file.
>>        rm -f $PIDFILE
>>    fi
>> }
>>
>> console() {
>>    echo "Running $APP_LONG_NAME..."
>>    getpid
>>    if [ "X$pid" =3D "X" ]
>>    then
>>        if [ "X$IGNORE_SIGNALS" =3D "X" ]
>>        then
>>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
>> wrapper.pidfile=3D$PIDFILE
>>        else
>>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
>> wrapper.pidfile=3D$PIDFILE wrapper.anchorfile=3D$ANCHORFILE
>>        fi
>>    else
>>        echo "$APP_LONG_NAME is already running."
>>        exit 1
>>    fi
>> }
>>
>> start() {
>>    echo "Starting $APP_LONG_NAME..."
>>    getpid
>>    if [ "X$pid" =3D "X" ]
>>    then
>>        if [ "X$IGNORE_SIGNALS" =3D "X" ]
>>        then
>>            if [ "X$RUN_AS_USER" =3D "X" ]
>>            then
>>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
>> wrapper.pidfile=3D$PIDFILE wrapper.daemonize=3DTRUE
>>            else
>>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD
>> $WRAPPER_CONF wrapper.pidfile=3D$PIDFILE wrapper.daemonize=3DTRUE"
>>            fi
>>        else
>>            if [ "X$RUN_AS_USER" =3D "X" ]
>>            then
>>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF
>> wrapper.pidfile=3D$PIDFILE wrapper.anchorfile=3D$ANCHORFILE
>> wrapper.ignore_signals=3DTRUE wrapper.daemonize=3DTRUE
>>            else
>>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD
>> $WRAPPER_CONF wrapper.pidfile=3D$PIDFILE wrapper.anchorfile=3D$ANCHORFILE
>> wrapper.ignore_signals=3DTRUE wrapper.daemonize=3DTRUE"
>>            fi
>>        fi
>>    else
>>        echo "$APP_LONG_NAME is already running."
>>        exit 1
>>    fi
>> }
>>
>> stopit() {
>>    echo "Stopping $APP_LONG_NAME..."
>>    getpid
>>    if [ "X$pid" =3D "X" ]
>>    then
>>        echo "$APP_LONG_NAME was not running."
>>    else
>>        if [ "X$IGNORE_SIGNALS" =3D "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=3D$pid
>>        CNT=3D0
>>        TOTCNT=3D0
>>        while [ "X$pid" !=3D "X" ]
>>        do
>>            # Loop for up to 5 minutes
>>            if [ "$TOTCNT" -lt "300" ]
>>            then
>>                if [ "$CNT" -lt "5" ]
>>                then
>>                    CNT=3D`expr $CNT + 1`
>>                else
>>                    echo "Waiting for $APP_LONG_NAME to exit..."
>>                    CNT=3D0
>>                fi
>>                TOTCNT=3D`expr $TOTCNT + 1`
>>
>>                sleep 1
>>
>>                testpid
>>            else
>>                pid=3D
>>            fi
>>        done
>>
>>        pid=3D$savepid
>>        testpid
>>        if [ "X$pid" !=3D "X" ]
>>        then
>>            echo "Timed out waiting for $APP_LONG_NAME to exit."
>>            echo "  Attempting a forced exit..."
>>            kill -9 $pid
>>        fi
>>
>>        pid=3D$savepid
>>        testpid
>>        if [ "X$pid" !=3D "X" ]
>>        then
>>            echo "Failed to stop $APP_LONG_NAME."
>>            exit 1
>>        else
>>            echo "Stopped $APP_LONG_NAME."
>>        fi
>>    fi
>> }
>>
>> status() {
>>    getpid
>>    if [ "X$pid" =3D "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" =3D "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')
>>        console
>>        ;;
>>
>>    'start')
>>        start
>>        ;;
>>
>>    'stop')
>>        stopit
>>        ;;
>>
>>    'restart')
>>        stopit
>>        start
>>        ;;
>>
>>    'status')
>>        status
>>        ;;
>>
>>    'dump')
>>        dump
>>        ;;
>>
>>    *)
>>        echo "Usage: $0 { console | start | stop | restart | status |
>> dump }"
>>        exit 1
>>        ;;
>> esac
>>
>> exit 0
>>
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Wrapper-user mailing list
Wra...@li...
 https://lists.sourceforge.net/lists/listinfo/wrapper-user



This message and any attachments (the "message") is=20
intended solely for the addressees and is confidential.=20
If you receive this message in error, please delete it and=20
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole=20
or partial, is prohibited except formal approval. The internet=20
can not guarantee the integrity of this message.=20
BNP PARIBAS (and its subsidiaries) shall (will) not=20
therefore be liable for the message if modified.=20

***************************************************************************=
*******************

BNP Paribas Private Bank London Branch is authorised=20
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the=20
United Kingdom.
 =20
BNP Paribas Fund Services UK Limited is authorised and=20
regulated by the Financial Services Authority.

Re: [SPAM] - Re: [SPAM] - Re: [Wrapper-user] PIDFILE + wrapper.working.dir - Bayesian Filter detected spam - Found word(s) list error remove in the Text body.

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

Stephane,
    I have not been able to test this new script anywhere other than 
linux at this point.  It
may have problems on other platforms still.   What platform are you 
running on?

    In answer to your first question.   It should still work on any 
directory layout.  The
script builds a fully qualified path by looking at the location of the 
script and then
modifying the PIDDIR variable so that it is absolute.  Take a look at 
the following:

REALDIR=`pwd`
FIRST_CHAR=`echo $PIDDIR | cut -c1,1`
if [ "$FIRST_CHAR" != "/" ]
then
        PIDDIR=$REALDIR/$PIDDIR
fi

    That and a similar section for the location of the configuration 
file are the only
changes.   The error you are getting is most likely being caused by this 
code.

    You may also be having problems with the line feeds of the script.   
Make sure
that is correct after you copied the script from my last mail.

Cheers,
Leif


Stéphane RIFF wrote:

> Leif ,
> Sorry for all those posts but when i try to launch the daemon with 
> your new script
> the shell complain about : "bad interpreter ........."
> So i can't test it , i'm waiting to see what you think about my last post
>
> Big thanks
>
> Stéphane RIFF wrote:
>
>> Leif ,
>>
>> I don't understand your last post: if the shell script use path like 
>> : PIDDIR : /usr/local/myapp/
>> (This is what i've done to make my wrapper work), if you change the 
>> location or OS you have to change
>> your script variables. Or i make a directory tree that can be move 
>> anywhere with relative path...
>>
>> Maybe i misunderstound so i gonna try your script to see what happen.
>>
>> Thanks for your answers
>> Bye
>>
>>
>>
>> Leif Mortenson wrote:
>>
>>> Stephane,
>>>    Ok, this was a bug in the shell script.   The pid file is created 
>>> after the working dir is
>>> changed but that is not taken into account by the shell script.
>>>
>>>    I have fixed this for the next release.  The shell script will 
>>> now always use fully qualified
>>> paths to avoid this issue.   I have attached the new shell script.  
>>> It should work for old
>>> versions of the Wrapper.
>>>
>>>    Let me know how it works for you.
>>>
>>> Cheers,
>>> Leif
>>>
>>> Stéphane RIFF wrote:
>>>
>>>> The user is the same (sure).
>>>>
>>>> The directory tree is :
>>>>       serviceroot
>>>>        |
>>>>        ---bin
>>>>        |      |
>>>>        |      ---wrapper
>>>>        |      |
>>>>        |      ---sh.script
>>>>        |
>>>>        ---conf
>>>>        |     |
>>>>        |     ---wrapper.conf
>>>>        |
>>>>        ---lib
>>>>        |
>>>>        ---logs
>>>>
>>>> In the wrapper.conf : wrapper.working.dir="../"
>>>> In sh.script : PIDDIR="."
>>>>
>>>> When i start the service (with user "steff"), the MYAPP.pid file is 
>>>> in the "serviceroot" directory.
>>>> When i want to stop (with user "steff"), the sh.script complains 
>>>> that "service not running". but
>>>> if i print $PIDFILE in the sh.script, it display : "./MYAPP.pid" : 
>>>> seems good if the working directory
>>>> is really set to "serviceroot"
>>>>
>>>> Maybe i missunderstood about working dir but if someone can points 
>>>> me to the right solution.....
>>>> Thanks to answerers
>>>>
>>>> Leif Mortenson wrote:
>>>>
>>>>> Stephane,
>>>>>    My first guess here is a permission problem.   Are you starting 
>>>>> the wrapper as the same
>>>>> user that you are later attempting stop it with?   I may have some 
>>>>> problems there but I have
>>>>> not heard of any to date.  Give me a little more info and I'll go 
>>>>> back and look over the
>>>>> script some more.
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>>>
>>>>> Stéphane RIFF wrote:
>>>>>
>>>>>> I have problem with the pid file :
>>>>>>   in sh.script.in i have PIDDIR=".", the 'start ' command seems 
>>>>>> to place pidfile in the right location.
>>>>>> but when i try to launch a 'stop' command the script tell me that 
>>>>>> the daemon isn't running .
>>>>>>
>>>>>> I also echo some variable and the $PIDFILE is : "./MYAPPNAME.pid" so
>>>>>> i don't understand why the line : "if [ -f $PIDFILE ]" is not true
>>>>>>
>>>>>> I don't know if i'm understandable but i suspect there a problem 
>>>>>> with the sh.script.in and the wrapper.working.dir.
>>>>>>
>>>>>> any hints are welcome
>>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> #! /bin/sh
>>>
>>> #
>>> # Copyright (c) 1999, 2004 Tanuki Software
>>> #
>>> # 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="@app.name@"
>>> APP_LONG_NAME="@app.long.name@"
>>>
>>> # 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
>>>
>>> # If specified, the Wrapper will be run as the specified user when 
>>> the 'start'
>>> #  command is passed to this script.  When running with the 
>>> 'console' command
>>> #  the current user will be used.
>>> # 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
>>>
>>> # Change spaces to ":" so the tokens can be parsed.
>>> SCRIPT=`echo $SCRIPT | sed -e 's; ;:;g'`
>>> # Get the real path to this script, resolving any symbolic links
>>> TOKENS=`echo $SCRIPT | sed -e 's;/; ;g'`
>>> REALPATH=
>>> for C in $TOKENS; do
>>>    REALPATH="$REALPATH/$C"
>>>    while [ -h "$REALPATH" ] ; do
>>>        LS="`ls -ld "$REALPATH"`"
>>>        LINK="`expr "$LS" : '.*-> \(.*\)$'`"
>>>        if expr "$LINK" : '/.*' > /dev/null; then
>>>            REALPATH="$LINK"
>>>        else
>>>            REALPATH="`dirname "$REALPATH"`""/$LINK"
>>>        fi
>>>    done
>>> done
>>> # Change ":" chars back to spaces.
>>> REALPATH=`echo $REALPATH | sed -e 's;:; ;g'`
>>>
>>> # 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_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"
>>> 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
>>>
>>> # Build the nice clause
>>> if [ "X$PRIORITY" = "X" ]
>>> then
>>>    CMDNICE=""
>>> else
>>>    CMDNICE="nice -$PRIORITY"
>>> fi
>>>
>>> # Check the configured 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
>>>
>>> getpid() {
>>>    if [ -f $PIDFILE ]
>>>    then
>>>        if [ -r $PIDFILE ]
>>>        then
>>>            pid=`cat $PIDFILE`
>>>            if [ "X$pid" != "X" ]
>>>            then
>>>                # Verify that a process with this pid is still running.
>>>                pid=`$PSEXE -p $pid | grep $pid | grep -v grep | awk 
>>> '{print $1}' | tail -1`
>>>                if [ "X$pid" = "X" ]
>>>                then
>>>                    # This is a stale pid file.
>>>                    rm -f $PIDFILE
>>>                    echo "Removed stale pid file: $PIDFILE"
>>>                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
>>>    fi
>>> }
>>>
>>> console() {
>>>    echo "Running $APP_LONG_NAME..."
>>>    getpid
>>>    if [ "X$pid" = "X" ]
>>>    then
>>>        if [ "X$IGNORE_SIGNALS" = "X" ]
>>>        then
>>>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>>> wrapper.pidfile=$PIDFILE
>>>        else
>>>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>>> wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE
>>>        fi
>>>    else
>>>        echo "$APP_LONG_NAME is already running."
>>>        exit 1
>>>    fi
>>> }
>>>
>>> start() {
>>>    echo "Starting $APP_LONG_NAME..."
>>>    getpid
>>>    if [ "X$pid" = "X" ]
>>>    then
>>>        if [ "X$IGNORE_SIGNALS" = "X" ]
>>>        then
>>>            if [ "X$RUN_AS_USER" = "X" ]
>>>            then
>>>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>>> wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE
>>>            else
>>>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD 
>>> $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE"
>>>            fi
>>>        else
>>>            if [ "X$RUN_AS_USER" = "X" ]
>>>            then
>>>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>>> wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE 
>>> wrapper.ignore_signals=TRUE wrapper.daemonize=TRUE
>>>            else
>>>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD 
>>> $WRAPPER_CONF wrapper.pidfile=$PIDFILE 
>>> wrapper.anchorfile=$ANCHORFILE wrapper.ignore_signals=TRUE 
>>> wrapper.daemonize=TRUE"
>>>            fi
>>>        fi
>>>    else
>>>        echo "$APP_LONG_NAME is already running."
>>>        exit 1
>>>    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
>>>            # Loop for up to 5 minutes
>>>            if [ "$TOTCNT" -lt "300" ]
>>>            then
>>>                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
>>>            else
>>>                pid=
>>>            fi
>>>        done
>>>
>>>        pid=$savepid
>>>        testpid
>>>        if [ "X$pid" != "X" ]
>>>        then
>>>            echo "Timed out waiting for $APP_LONG_NAME to exit."
>>>            echo "  Attempting a forced exit..."
>>>            kill -9 $pid
>>>        fi
>>>
>>>        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')
>>>        console
>>>        ;;
>>>
>>>    'start')
>>>        start
>>>        ;;
>>>
>>>    'stop')
>>>        stopit
>>>        ;;
>>>
>>>    'restart')
>>>        stopit
>>>        start
>>>        ;;
>>>
>>>    'status')
>>>        status
>>>        ;;
>>>
>>>    'dump')
>>>        dump
>>>        ;;
>>>
>>>    *)
>>>        echo "Usage: $0 { console | start | stop | restart | status | 
>>> dump }"
>>>        exit 1
>>>        ;;
>>> esac
>>>
>>> exit 0
>>>  
>>

Re: [SPAM] - Re: [SPAM] - Re: [Wrapper-user] PIDFILE + wrapper.working.dir - Bayesian Filter detected spam - Found word(s) list error remove in the Text body.

[<ste...@ce...>]

Leif ,
Sorry for all those posts but when i try to launch the daemon with your 
new script
the shell complain about : "bad interpreter ........."
So i can't test it , i'm waiting to see what you think about my last post

Big thanks

Stéphane RIFF wrote:

> Leif ,
>
> I don't understand your last post: if the shell script use path like : 
> PIDDIR : /usr/local/myapp/
> (This is what i've done to make my wrapper work), if you change the 
> location or OS you have to change
> your script variables. Or i make a directory tree that can be move 
> anywhere with relative path...
>
> Maybe i misunderstound so i gonna try your script to see what happen.
>
> Thanks for your answers
> Bye
>
>
>
> Leif Mortenson wrote:
>
>> Stephane,
>>    Ok, this was a bug in the shell script.   The pid file is created 
>> after the working dir is
>> changed but that is not taken into account by the shell script.
>>
>>    I have fixed this for the next release.  The shell script will now 
>> always use fully qualified
>> paths to avoid this issue.   I have attached the new shell script.  
>> It should work for old
>> versions of the Wrapper.
>>
>>    Let me know how it works for you.
>>
>> Cheers,
>> Leif
>>
>> Stéphane RIFF wrote:
>>
>>> The user is the same (sure).
>>>
>>> The directory tree is :
>>>       serviceroot
>>>        |
>>>        ---bin
>>>        |      |
>>>        |      ---wrapper
>>>        |      |
>>>        |      ---sh.script
>>>        |
>>>        ---conf
>>>        |     |
>>>        |     ---wrapper.conf
>>>        |
>>>        ---lib
>>>        |
>>>        ---logs
>>>
>>> In the wrapper.conf : wrapper.working.dir="../"
>>> In sh.script : PIDDIR="."
>>>
>>> When i start the service (with user "steff"), the MYAPP.pid file is 
>>> in the "serviceroot" directory.
>>> When i want to stop (with user "steff"), the sh.script complains 
>>> that "service not running". but
>>> if i print $PIDFILE in the sh.script, it display : "./MYAPP.pid" : 
>>> seems good if the working directory
>>> is really set to "serviceroot"
>>>
>>> Maybe i missunderstood about working dir but if someone can points 
>>> me to the right solution.....
>>> Thanks to answerers
>>>
>>> Leif Mortenson wrote:
>>>
>>>> Stephane,
>>>>    My first guess here is a permission problem.   Are you starting 
>>>> the wrapper as the same
>>>> user that you are later attempting stop it with?   I may have some 
>>>> problems there but I have
>>>> not heard of any to date.  Give me a little more info and I'll go 
>>>> back and look over the
>>>> script some more.
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> Stéphane RIFF wrote:
>>>>
>>>>> I have problem with the pid file :
>>>>>   in sh.script.in i have PIDDIR=".", the 'start ' command seems to 
>>>>> place pidfile in the right location.
>>>>> but when i try to launch a 'stop' command the script tell me that 
>>>>> the daemon isn't running .
>>>>>
>>>>> I also echo some variable and the $PIDFILE is : "./MYAPPNAME.pid" so
>>>>> i don't understand why the line : "if [ -f $PIDFILE ]" is not true
>>>>>
>>>>> I don't know if i'm understandable but i suspect there a problem 
>>>>> with the sh.script.in and the wrapper.working.dir.
>>>>>
>>>>> any hints are welcome
>>>>> Thanks
>>>>
>>>>
>>>>
>>
>> ------------------------------------------------------------------------
>>
>> #! /bin/sh
>>
>> #
>> # Copyright (c) 1999, 2004 Tanuki Software
>> #
>> # 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="@app.name@"
>> APP_LONG_NAME="@app.long.name@"
>>
>> # 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
>>
>> # If specified, the Wrapper will be run as the specified user when 
>> the 'start'
>> #  command is passed to this script.  When running with the 'console' 
>> command
>> #  the current user will be used.
>> # 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
>>
>> # Change spaces to ":" so the tokens can be parsed.
>> SCRIPT=`echo $SCRIPT | sed -e 's; ;:;g'`
>> # Get the real path to this script, resolving any symbolic links
>> TOKENS=`echo $SCRIPT | sed -e 's;/; ;g'`
>> REALPATH=
>> for C in $TOKENS; do
>>    REALPATH="$REALPATH/$C"
>>    while [ -h "$REALPATH" ] ; do
>>        LS="`ls -ld "$REALPATH"`"
>>        LINK="`expr "$LS" : '.*-> \(.*\)$'`"
>>        if expr "$LINK" : '/.*' > /dev/null; then
>>            REALPATH="$LINK"
>>        else
>>            REALPATH="`dirname "$REALPATH"`""/$LINK"
>>        fi
>>    done
>> done
>> # Change ":" chars back to spaces.
>> REALPATH=`echo $REALPATH | sed -e 's;:; ;g'`
>>
>> # 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_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"
>> 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
>>
>> # Build the nice clause
>> if [ "X$PRIORITY" = "X" ]
>> then
>>    CMDNICE=""
>> else
>>    CMDNICE="nice -$PRIORITY"
>> fi
>>
>> # Check the configured 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
>>
>> getpid() {
>>    if [ -f $PIDFILE ]
>>    then
>>        if [ -r $PIDFILE ]
>>        then
>>            pid=`cat $PIDFILE`
>>            if [ "X$pid" != "X" ]
>>            then
>>                # Verify that a process with this pid is still running.
>>                pid=`$PSEXE -p $pid | grep $pid | grep -v grep | awk 
>> '{print $1}' | tail -1`
>>                if [ "X$pid" = "X" ]
>>                then
>>                    # This is a stale pid file.
>>                    rm -f $PIDFILE
>>                    echo "Removed stale pid file: $PIDFILE"
>>                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
>>    fi
>> }
>>
>> console() {
>>    echo "Running $APP_LONG_NAME..."
>>    getpid
>>    if [ "X$pid" = "X" ]
>>    then
>>        if [ "X$IGNORE_SIGNALS" = "X" ]
>>        then
>>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>> wrapper.pidfile=$PIDFILE
>>        else
>>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>> wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE
>>        fi
>>    else
>>        echo "$APP_LONG_NAME is already running."
>>        exit 1
>>    fi
>> }
>>
>> start() {
>>    echo "Starting $APP_LONG_NAME..."
>>    getpid
>>    if [ "X$pid" = "X" ]
>>    then
>>        if [ "X$IGNORE_SIGNALS" = "X" ]
>>        then
>>            if [ "X$RUN_AS_USER" = "X" ]
>>            then
>>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>> wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE
>>            else
>>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD 
>> $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE"
>>            fi
>>        else
>>            if [ "X$RUN_AS_USER" = "X" ]
>>            then
>>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF 
>> wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE 
>> wrapper.ignore_signals=TRUE wrapper.daemonize=TRUE
>>            else
>>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD 
>> $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE 
>> wrapper.ignore_signals=TRUE wrapper.daemonize=TRUE"
>>            fi
>>        fi
>>    else
>>        echo "$APP_LONG_NAME is already running."
>>        exit 1
>>    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
>>            # Loop for up to 5 minutes
>>            if [ "$TOTCNT" -lt "300" ]
>>            then
>>                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
>>            else
>>                pid=
>>            fi
>>        done
>>
>>        pid=$savepid
>>        testpid
>>        if [ "X$pid" != "X" ]
>>        then
>>            echo "Timed out waiting for $APP_LONG_NAME to exit."
>>            echo "  Attempting a forced exit..."
>>            kill -9 $pid
>>        fi
>>
>>        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')
>>        console
>>        ;;
>>
>>    'start')
>>        start
>>        ;;
>>
>>    'stop')
>>        stopit
>>        ;;
>>
>>    'restart')
>>        stopit
>>        start
>>        ;;
>>
>>    'status')
>>        status
>>        ;;
>>
>>    'dump')
>>        dump
>>        ;;
>>
>>    *)
>>        echo "Usage: $0 { console | start | stop | restart | status | 
>> dump }"
>>        exit 1
>>        ;;
>> esac
>>
>> exit 0
>>  
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [SPAM] - Re: [Wrapper-user] PIDFILE + wrapper.working.dir - Bayesian Filter detected spam

[<ste...@ce...>]

Leif ,

I don't understand your last post: if the shell script use path like : 
PIDDIR : /usr/local/myapp/
(This is what i've done to make my wrapper work), if you change the 
location or OS you have to change
your script variables. Or i make a directory tree that can be move 
anywhere with relative path...

Maybe i misunderstound so i gonna try your script to see what happen.

Thanks for your answers
Bye



Leif Mortenson wrote:

> Stephane,
>    Ok, this was a bug in the shell script.   The pid file is created 
> after the working dir is
> changed but that is not taken into account by the shell script.
>
>    I have fixed this for the next release.  The shell script will now 
> always use fully qualified
> paths to avoid this issue.   I have attached the new shell script.  It 
> should work for old
> versions of the Wrapper.
>
>    Let me know how it works for you.
>
> Cheers,
> Leif
>
> Stéphane RIFF wrote:
>
>> The user is the same (sure).
>>
>> The directory tree is :
>>       serviceroot
>>        |
>>        ---bin
>>        |      |
>>        |      ---wrapper
>>        |      |
>>        |      ---sh.script
>>        |
>>        ---conf
>>        |     |
>>        |     ---wrapper.conf
>>        |
>>        ---lib
>>        |
>>        ---logs
>>
>> In the wrapper.conf : wrapper.working.dir="../"
>> In sh.script : PIDDIR="."
>>
>> When i start the service (with user "steff"), the MYAPP.pid file is 
>> in the "serviceroot" directory.
>> When i want to stop (with user "steff"), the sh.script complains that 
>> "service not running". but
>> if i print $PIDFILE in the sh.script, it display : "./MYAPP.pid" : 
>> seems good if the working directory
>> is really set to "serviceroot"
>>
>> Maybe i missunderstood about working dir but if someone can points me 
>> to the right solution.....
>> Thanks to answerers
>>
>> Leif Mortenson wrote:
>>
>>> Stephane,
>>>    My first guess here is a permission problem.   Are you starting 
>>> the wrapper as the same
>>> user that you are later attempting stop it with?   I may have some 
>>> problems there but I have
>>> not heard of any to date.  Give me a little more info and I'll go 
>>> back and look over the
>>> script some more.
>>>
>>> Cheers,
>>> Leif
>>>
>>> Stéphane RIFF wrote:
>>>
>>>> I have problem with the pid file :
>>>>   in sh.script.in i have PIDDIR=".", the 'start ' command seems to 
>>>> place pidfile in the right location.
>>>> but when i try to launch a 'stop' command the script tell me that 
>>>> the daemon isn't running .
>>>>
>>>> I also echo some variable and the $PIDFILE is : "./MYAPPNAME.pid" so
>>>> i don't understand why the line : "if [ -f $PIDFILE ]" is not true
>>>>
>>>> I don't know if i'm understandable but i suspect there a problem 
>>>> with the sh.script.in and the wrapper.working.dir.
>>>>
>>>> any hints are welcome
>>>> Thanks
>>>
>>>
>
>------------------------------------------------------------------------
>
>#! /bin/sh
>
>#
># Copyright (c) 1999, 2004 Tanuki Software
>#
># 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="@app.name@"
>APP_LONG_NAME="@app.long.name@"
>
># 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
>
># If specified, the Wrapper will be run as the specified user when the 'start'
>#  command is passed to this script.  When running with the 'console' command
>#  the current user will be used.
># 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
>
># Change spaces to ":" so the tokens can be parsed.
>SCRIPT=`echo $SCRIPT | sed -e 's; ;:;g'`
># Get the real path to this script, resolving any symbolic links
>TOKENS=`echo $SCRIPT | sed -e 's;/; ;g'`
>REALPATH=
>for C in $TOKENS; do
>    REALPATH="$REALPATH/$C"
>    while [ -h "$REALPATH" ] ; do
>        LS="`ls -ld "$REALPATH"`"
>        LINK="`expr "$LS" : '.*-> \(.*\)$'`"
>        if expr "$LINK" : '/.*' > /dev/null; then
>            REALPATH="$LINK"
>        else
>            REALPATH="`dirname "$REALPATH"`""/$LINK"
>        fi
>    done
>done
># Change ":" chars back to spaces.
>REALPATH=`echo $REALPATH | sed -e 's;:; ;g'`
>
># 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_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"
>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
>
># Build the nice clause
>if [ "X$PRIORITY" = "X" ]
>then
>    CMDNICE=""
>else
>    CMDNICE="nice -$PRIORITY"
>fi
>
># Check the configured 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
>
>getpid() {
>    if [ -f $PIDFILE ]
>    then
>        if [ -r $PIDFILE ]
>        then
>            pid=`cat $PIDFILE`
>            if [ "X$pid" != "X" ]
>            then
>                # Verify that a process with this pid is still running.
>                pid=`$PSEXE -p $pid | grep $pid | grep -v grep | awk '{print $1}' | tail -1`
>                if [ "X$pid" = "X" ]
>                then
>                    # This is a stale pid file.
>                    rm -f $PIDFILE
>                    echo "Removed stale pid file: $PIDFILE"
>                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
>    fi
>}
>
>console() {
>    echo "Running $APP_LONG_NAME..."
>    getpid
>    if [ "X$pid" = "X" ]
>    then
>        if [ "X$IGNORE_SIGNALS" = "X" ]
>        then
>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE
>        else
>            exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE
>        fi
>    else
>        echo "$APP_LONG_NAME is already running."
>        exit 1
>    fi
>}
> 
>start() {
>    echo "Starting $APP_LONG_NAME..."
>    getpid
>    if [ "X$pid" = "X" ]
>    then
>        if [ "X$IGNORE_SIGNALS" = "X" ]
>        then
>            if [ "X$RUN_AS_USER" = "X" ]
>            then
>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE
>            else
>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.daemonize=TRUE"
>            fi
>        else
>            if [ "X$RUN_AS_USER" = "X" ]
>            then
>                exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE wrapper.ignore_signals=TRUE wrapper.daemonize=TRUE
>            else
>                su -m $RUN_AS_USER -c "exec $CMDNICE $WRAPPER_CMD $WRAPPER_CONF wrapper.pidfile=$PIDFILE wrapper.anchorfile=$ANCHORFILE wrapper.ignore_signals=TRUE wrapper.daemonize=TRUE"
>            fi
>        fi
>    else
>        echo "$APP_LONG_NAME is already running."
>        exit 1
>    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
>            # Loop for up to 5 minutes
>            if [ "$TOTCNT" -lt "300" ]
>            then
>                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
>            else
>                pid=
>            fi
>        done
>
>        pid=$savepid
>        testpid
>        if [ "X$pid" != "X" ]
>        then
>            echo "Timed out waiting for $APP_LONG_NAME to exit."
>            echo "  Attempting a forced exit..."
>            kill -9 $pid
>        fi
>
>        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')
>        console
>        ;;
>
>    'start')
>        start
>        ;;
>
>    'stop')
>        stopit
>        ;;
>
>    'restart')
>        stopit
>        start
>        ;;
>
>    'status')
>        status
>        ;;
>
>    'dump')
>        dump
>        ;;
>
>    *)
>        echo "Usage: $0 { console | start | stop | restart | status | dump }"
>        exit 1
>        ;;
>esac
>
>exit 0
>  
>

Re: [SPAM] - Re: [Wrapper-user] PIDFILE + wrapper.working.dir - Bayesian Filter detected spam

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

Stephane,
    Ok, this was a bug in the shell script.   The pid file is created 
after the working dir is
changed but that is not taken into account by the shell script.

    I have fixed this for the next release.  The shell script will now 
always use fully qualified
paths to avoid this issue.   I have attached the new shell script.  It 
should work for old
versions of the Wrapper.

    Let me know how it works for you.

Cheers,
Leif

Stéphane RIFF wrote:

> The user is the same (sure).
>
> The directory tree is :
>       serviceroot
>        |
>        ---bin
>        |      |
>        |      ---wrapper
>        |      |
>        |      ---sh.script
>        |
>        ---conf
>        |     |
>        |     ---wrapper.conf
>        |
>        ---lib
>        |
>        ---logs
>
> In the wrapper.conf : wrapper.working.dir="../"
> In sh.script : PIDDIR="."
>
> When i start the service (with user "steff"), the MYAPP.pid file is in 
> the "serviceroot" directory.
> When i want to stop (with user "steff"), the sh.script complains that 
> "service not running". but
> if i print $PIDFILE in the sh.script, it display : "./MYAPP.pid" : 
> seems good if the working directory
> is really set to "serviceroot"
>
> Maybe i missunderstood about working dir but if someone can points me 
> to the right solution.....
> Thanks to answerers
>
> Leif Mortenson wrote:
>
>> Stephane,
>>    My first guess here is a permission problem.   Are you starting 
>> the wrapper as the same
>> user that you are later attempting stop it with?   I may have some 
>> problems there but I have
>> not heard of any to date.  Give me a little more info and I'll go 
>> back and look over the
>> script some more.
>>
>> Cheers,
>> Leif
>>
>> Stéphane RIFF wrote:
>>
>>> I have problem with the pid file :
>>>   in sh.script.in i have PIDDIR=".", the 'start ' command seems to 
>>> place pidfile in the right location.
>>> but when i try to launch a 'stop' command the script tell me that 
>>> the daemon isn't running .
>>>
>>> I also echo some variable and the $PIDFILE is : "./MYAPPNAME.pid" so
>>> i don't understand why the line : "if [ -f $PIDFILE ]" is not true
>>>
>>> I don't know if i'm understandable but i suspect there a problem 
>>> with the sh.script.in and the wrapper.working.dir.
>>>
>>> any hints are welcome
>>> Thanks
>>

Re: [Wrapper-user] working dir on windows and unix

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

Nick,
    You stumbled onto a bug in the shell script.  The problem is that 
the paths to the wrapper
conf and pid files are relative.   The shell script is expecting them to 
be relative to the location
of the shell script, and thus home directory.  After changing the 
working directory, this is no
longer true.

    I am still working on cleaning this up for the next release.

    I have attached a shell script which will use fully qualified paths 
for the locations of the
pid files and config file.   The script assumes that the sh is in the 
same directory as the
Wrapper binary.

    In your case you are putting the shell in the root so you will need 
to do a little more
work  Change the value of the WRAPPER_CONF and PIDDIR variables in the 
script
to appropriate values.

    Then when you launch the Wrapper, rather than placing the 
wrapper.working.dir
property in the wrapper.conf, either pass it in as a parameter.   
"../../" for Windows
or "." for UNIX.
    Another option is to leave it in the conf file, but use the value 
"/".  This assumes the
root on both platforms.  (Is that really what you want in UNIX??)

    I would appreciate your feedback on this and will try to get it 
cleaned up for the
next release.  I am debating modifying the UNIX version of the Wrapper 
so that
it starts with forcing the working directory to the location of the 
binary as is done
on Windows.   It would be an incompatibility, but it would clean things 
up in the
long run...

Cheers,
Leif

nic...@uk... wrote:

>Hi,
>
>I am trying to get my app working under windows and linux with the same
>config & behaviour
>
>My dir structure looks like this
>{root}/MyApp.sh
>{root}/MyApp.bat
>{root}/wrapper/bin
>{root}/wrapper/conf
>{root}/wrapper/lib
>
>1) I want my scripts are outside of bin - {root}
>2) I want my running dir is outside of bin  - {root}
>
>I have modified the scripts to find the wrapper(.exe) binary & config from
>where they are.
>I have set the wrapper.working.dir property to ../../ - in order to make it
>run in the {root} dir.
>On windows my config works fine. If I leave the unmodified scripts in the
>{root}/wrapper/bin everything works fine also.
>
>But on linux, the problem I have is that the wrapper binary doesnt start in
>./wrapper/bin - and hence ../../ doesnt make sense - and all paths in the
>wrapper.conf are off.
>What I am struggling with is how to modify the script so that it runs the
>wrapper binary in the {root}/wrapper/bin dir rather than the current dir.
>
>Thanks.
>
>-Nick
>  
>

RE: [Wrapper-user] Re-read wrapper.conf on restart?

[Ori A. <oa...@me...>]

Leif,
Thanks for pointing out the problems with my solution, luckily I didn't fall
into any of the problem categories, but it's just luck :-)
I was looking for the smallest code change available for it to work.
I want to upgrade my version anyway, so I'll look into the 3.2.0 that has a
complete solution for this.

Regards,

Ori

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: Monday, December 06, 2004 9:11 AM
To: wra...@li...
Subject: Re: [Wrapper-user] Re-read wrapper.conf on restart?

Todd,
I went in today and got this implemented for the the next Wrapper
release (3.2.0).
It will be enabled using a new wrapper.restart.reload_configuration
property.

The patch submitted by Ori will work for most cases. The exception is if
you have
declared any filters or have any dependent services defined on Windows
versions.
Those will both leak memory on each restart but the leak is pretty
small. Everything
else should work for you.
This patch will also have problems if you remove properties from the
configuration
file. You can change or add property values but this patch will not
remove them.

The implementation in the 3.2.0 release is done a bit differently so the
above
problems are all resolved there.

Thanks Ori.

Cheers,
Leif

Ori Argov wrote:

> Hi Todd,
>
> I'm using version 3.0.2 and I also needed this feature (I should
> really upgrade though...).
>
> What I did was add a line to the following function in wrapper.c:
>
> void wrapperRestartRequested() {
>
> log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_STATUS, "JVM requested a
> restart.");
>
> *// THE FOLLOWING LINE WAS ADDED*
>
> *loadProperties(properties, wrapperData->configFile);*
>
> wrapperLoadConfiguration();
>
> wrapperRestartProcess();
>
> }
>
> Then, calling a WrapperManager.restart() will also re-read the
> properties file.
>
> I also found it useful to use the #include feature of the conf files
> in this case and add dynamic classpath
>
> Entries to another conf file which is always included by the main one.
>
> Hope it helps,
>
> Ori
>
> ------------------------------------------------------------------------
>
> *From:* wra...@li...
> [mailto:wra...@li...] *On Behalf Of *Todd
> Klaus
> *Sent:* Saturday, December 04, 2004 4:30 AM
> *To:* wra...@li...
> *Subject:* [Wrapper-user] Re-read wrapper.conf on restart?
>
> Hi,
>
> I am using Wrapper 3.0.5 and have the following classpath set in
> wrapper.conf:
>
> wrapper.java.classpath.1=../lib/*.jar
>
> wrapper.java.classpath.2=../lib/*.zip
>
> I would like to support upgrade capability in my application whereby
> new jars are sent to the application via JMS and written to the
> applications lib directory (referenced by the classpath above). As
> soon as the new jars are downloaded, I restart the app using
> WrapperManager.restart(). Unfortunately, it seems that the wrapper
> does not rebuild the classpath on restart, because I get ClassNotFound
> exceptions for classes referenced in the new jars after the restart. A
> complete shutdown and restart of the app works fine (but doesn't meet
> the goal of being fully automatic!). These are usually new third-party
> jars, so they were not in the classpath before the upgrade.
>
> I even tried programmatically modifying wrapper.conf to explicity add
> a reference to the new jar, like this:
>
> wrapper.java.classpath.3=../lib/newjar.zip
>
> but it seems that the wrapper doesn't even re-read wrapper.conf on a
> restart.
>
> Is there any way to force the wrapper to re-read the conf file? Any
> other way to accomplish this? Any comments/suggestions welcome!
>
> Thanks,
>
> Todd
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: [Wrapper-user] Re-read wrapper.conf on restart?

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

Todd,
I went in today and got this implemented for the the next Wrapper
release (3.2.0).
It will be enabled using a new wrapper.restart.reload_configuration
property.

The patch submitted by Ori will work for most cases. The exception is if
you have
declared any filters or have any dependent services defined on Windows
versions.
Those will both leak memory on each restart but the leak is pretty
small. Everything
else should work for you.
This patch will also have problems if you remove properties from the
configuration
file. You can change or add property values but this patch will not
remove them.

The implementation in the 3.2.0 release is done a bit differently so the
above
problems are all resolved there.

Thanks Ori.

Cheers,
Leif

Ori Argov wrote:

> Hi Todd,
>
> I'm using version 3.0.2 and I also needed this feature (I should
> really upgrade though...).
>
> What I did was add a line to the following function in wrapper.c:
>
> void wrapperRestartRequested() {
>
> log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_STATUS, "JVM requested a
> restart.");
>
> *// THE FOLLOWING LINE WAS ADDED*
>
> *loadProperties(properties, wrapperData->configFile);*
>
> wrapperLoadConfiguration();
>
> wrapperRestartProcess();
>
> }
>
> Then, calling a WrapperManager.restart() will also re-read the
> properties file.
>
> I also found it useful to use the #include feature of the conf files
> in this case and add dynamic classpath
>
> Entries to another conf file which is always included by the main one.
>
> Hope it helps,
>
> Ori
>
> ------------------------------------------------------------------------
>
> *From:* wra...@li...
> [mailto:wra...@li...] *On Behalf Of *Todd
> Klaus
> *Sent:* Saturday, December 04, 2004 4:30 AM
> *To:* wra...@li...
> *Subject:* [Wrapper-user] Re-read wrapper.conf on restart?
>
> Hi,
>
> I am using Wrapper 3.0.5 and have the following classpath set in
> wrapper.conf:
>
> wrapper.java.classpath.1=../lib/*.jar
>
> wrapper.java.classpath.2=../lib/*.zip
>
> I would like to support upgrade capability in my application whereby
> new jars are sent to the application via JMS and written to the
> applications lib directory (referenced by the classpath above). As
> soon as the new jars are downloaded, I restart the app using
> WrapperManager.restart(). Unfortunately, it seems that the wrapper
> does not rebuild the classpath on restart, because I get ClassNotFound
> exceptions for classes referenced in the new jars after the restart. A
> complete shutdown and restart of the app works fine (but doesn't meet
> the goal of being fully automatic!). These are usually new third-party
> jars, so they were not in the classpath before the upgrade.
>
> I even tried programmatically modifying wrapper.conf to explicity add
> a reference to the new jar, like this:
>
> wrapper.java.classpath.3=../lib/newjar.zip
>
> but it seems that the wrapper doesn't even re-read wrapper.conf on a
> restart.
>
> Is there any way to force the wrapper to re-read the conf file? Any
> other way to accomplish this? Any comments/suggestions welcome!
>
> Thanks,
>
> Todd
>

[Wrapper-user] RE: Re-read wrapper.conf on restart?

[Lancelot H. <lan...@ac...>]

We can modify its source codes to accomplish this (let wrapper reload the
configuration when restarting).

Thanks

Lance
  -----Original Message-----
  From: Todd Klaus [mailto:tod...@ac...]
  Sent: 2004?12?4? 10:30
  To: wra...@li...
  Subject: Re-read wrapper.conf on restart?


  Hi,



  I am using Wrapper 3.0.5 and have the following classpath set in
wrapper.conf:



  wrapper.java.classpath.1=../lib/*.jar

  wrapper.java.classpath.2=../lib/*.zip



  I would like to support upgrade capability in my application whereby new
jars are sent to the application via JMS and written to the applications lib
directory (referenced by the classpath above).  As soon as the new jars are
downloaded, I restart the app using WrapperManager.restart().
Unfortunately, it seems that the wrapper does not rebuild the classpath on
restart, because I get ClassNotFound exceptions for classes referenced in
the new jars after the restart.  A complete shutdown and restart of the app
works fine (but doesn't meet the goal of being fully automatic!).  These are
usually new third-party jars, so they were not in the classpath before the
upgrade.



  I even tried programmatically modifying wrapper.conf to explicity add a
reference to the new jar, like this:



  wrapper.java.classpath.3=../lib/newjar.zip



  but it seems that the wrapper doesn't even re-read wrapper.conf on a
restart.



  Is there any way to force the wrapper to re-read the conf file?  Any other
way to accomplish this?  Any comments/suggestions welcome!



  Thanks,

  Todd

RE: [Wrapper-user] Re-read wrapper.conf on restart?

[Ori A. <oa...@me...>]

Hi Todd,

I'm using version 3.0.2 and I also needed this feature (I should really
upgrade though...).

What I did was add a line to the following function in wrapper.c:

 

void wrapperRestartRequested() {

    log_printf(WRAPPER_SOURCE_WRAPPER, LEVEL_STATUS, "JVM requested a
restart.");

    // THE FOLLOWING LINE WAS ADDED

    loadProperties(properties, wrapperData->configFile);

    wrapperLoadConfiguration();

    wrapperRestartProcess();

}

 

Then, calling a WrapperManager.restart() will also re-read the properties
file.

I also found it useful to use the #include feature of the conf files in this
case and add dynamic classpath

Entries to another conf file which is always included by the main one.

 

Hope it helps,

 

Ori

  _____  

From: wra...@li...
[mailto:wra...@li...] On Behalf Of Todd Klaus
Sent: Saturday, December 04, 2004 4:30 AM
To: wra...@li...
Subject: [Wrapper-user] Re-read wrapper.conf on restart?

 

Hi,

 

I am using Wrapper 3.0.5 and have the following classpath set in
wrapper.conf:

 

wrapper.java.classpath.1=../lib/*.jar

wrapper.java.classpath.2=../lib/*.zip

 

I would like to support upgrade capability in my application whereby new
jars are sent to the application via JMS and written to the applications lib
directory (referenced by the classpath above).  As soon as the new jars are
downloaded, I restart the app using WrapperManager.restart().
Unfortunately, it seems that the wrapper does not rebuild the classpath on
restart, because I get ClassNotFound exceptions for classes referenced in
the new jars after the restart.  A complete shutdown and restart of the app
works fine (but doesn't meet the goal of being fully automatic!).  These are
usually new third-party jars, so they were not in the classpath before the
upgrade.

 

I even tried programmatically modifying wrapper.conf to explicity add a
reference to the new jar, like this:

 

wrapper.java.classpath.3=../lib/newjar.zip

 

but it seems that the wrapper doesn't even re-read wrapper.conf on a
restart.  

 

Is there any way to force the wrapper to re-read the conf file?  Any other
way to accomplish this?  Any comments/suggestions welcome!

 

Thanks,

Todd

 

 



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Wrapper-user] Re-read wrapper.conf on restart?

[Todd K. <tod...@ac...>]

Hi,

=20

I am using Wrapper 3.0.5 and have the following classpath set in
wrapper.conf:

=20

wrapper.java.classpath.1=3D../lib/*.jar

wrapper.java.classpath.2=3D../lib/*.zip

=20

I would like to support upgrade capability in my application whereby new
jars are sent to the application via JMS and written to the applications
lib directory (referenced by the classpath above).  As soon as the new
jars are downloaded, I restart the app using WrapperManager.restart().
Unfortunately, it seems that the wrapper does not rebuild the classpath
on restart, because I get ClassNotFound exceptions for classes
referenced in the new jars after the restart.  A complete shutdown and
restart of the app works fine (but doesn't meet the goal of being fully
automatic!).  These are usually new third-party jars, so they were not
in the classpath before the upgrade.

=20

I even tried programmatically modifying wrapper.conf to explicity add a
reference to the new jar, like this:

=20

wrapper.java.classpath.3=3D../lib/newjar.zip

=20

but it seems that the wrapper doesn't even re-read wrapper.conf on a
restart. =20

=20

Is there any way to force the wrapper to re-read the conf file?  Any
other way to accomplish this?  Any comments/suggestions welcome!

=20

Thanks,

Todd

=20

=20

[Wrapper-user] Re: Need ability to become different user on wrapper launch

[Stundzig, S. <Ste...@gd...>]

Hi leif,

you've done a great job with the wrapper tool. I love it. :-)

Your current approach of using the 'su -m' to change the user which =
executes the wrapper on unix has a tiny drawback. 'su -m' changes only =
the effective UID and not the real UID as with 'su -'. This causes =
problems on tools they use the UID and not the EUID as for example 'rcs' =
wich is called by the RCSFileProvider of JSPWiki.

I've replaced the=20
	su -m $RUN_AS_USER -c "exec $CMDNICE....
in my sh start script to
	su - $RUN_AS_USER -c "cd `dirname $REALPATH`; exec $CMDNICE...
and it works as expected.=20

Regards
	Steffen...

[Wrapper-user] working dir on windows and unix

[<nic...@uk...>]

Hi,

I am trying to get my app working under windows and linux with the same
config & behaviour

My dir structure looks like this
{root}/MyApp.sh
{root}/MyApp.bat
{root}/wrapper/bin
{root}/wrapper/conf
{root}/wrapper/lib

1) I want my scripts are outside of bin - {root}
2) I want my running dir is outside of bin  - {root}

I have modified the scripts to find the wrapper(.exe) binary & config from
where they are.
I have set the wrapper.working.dir property to ../../ - in order to make it
run in the {root} dir.
On windows my config works fine. If I leave the unmodified scripts in the
{root}/wrapper/bin everything works fine also.

But on linux, the problem I have is that the wrapper binary doesnt start in
./wrapper/bin - and hence ../../ doesnt make sense - and all paths in the
wrapper.conf are off.
What I am struggling with is how to modify the script so that it runs the
wrapper binary in the {root}/wrapper/bin dir rather than the current dir.

Thanks.

-Nick



This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.

[Wrapper-user] Auto registration of Java Service Wrapper MBean

[<nic...@uk...>]

Hi,

With embedded JMX server in JDK1.5, it would be really nice if Java Service
Wrapper could auto-register its JMX bean (upon jdk1.5 detection).
This is especially so when using the WrapperStartStopApp and
WrapperSimpleApp integration methods.

Below is the code/config I have written to register JMX beans using the
WrapperStartStopApp integration means.

It would be much nicer if it was built into the wrapper itself - and
enabled via a wrapper.conf parameter
wrapper.jmx.enable=true
wrapper.jmx.name="wrapper:type=Java Service Wrapper Control"

Its a fantastic utility by the way. Documentation is excellent. Its
well-baked. It Just Works. ;-)

Cheers,
Nick


--------------- conf ---------------
wrapper.java.additional.2=-Dcom.sun.management.jmxremote
wrapper.java.additional.3=-Dcom.sun.management.jmxremote.port=4242
wrapper.java.additional.4=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.5=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.6=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.7=-Dcom.sun.management.jmxremote.password.file=jmxremote.password
wrapper.java.additional.8=-Dwrapper.mbean.name="wrapper:type=Java Service
Wrapper Control"
--------------- code ---------------
public class WrapperStartStopWithJMXApp {
    private static final String DEFAULT_WRAPPER_MBEAN_NAME =
"wrapper:type=Java Service Wrapper Control";
    private static final String WRAPPER_BEAN_NAME_KEY =
"wrapper.mbean.name";

    public static void main(String[] args) {
        try {
            Class.forName("javax.management.MBeanServer");
            registerMbeans();
        }
        catch (ClassNotFoundException ignore) {
        }
        WrapperStartStopApp.main(args);
    }

    private static void registerMbeans()  {
        try {
            System.out.println("JDK 1.5 detected, registering Java Service
Wrapper MBean");
            WrapperManager managerBean = new WrapperManager();
            ObjectName name = new ObjectName(getName());
            MBeanServer server =
ManagementFactory.getPlatformMBeanServer();
            server.registerMBean(managerBean, name);
        }
        catch (Exception e) {
            System.err.println("Failed to register ServiceWrapper MBeans");
            e.printStackTrace();
        }
    }

    private static String getName() {
        String name = System.getProperty(WRAPPER_BEAN_NAME_KEY);
        if (name == null) {
            System.out.println("Property \"" + WRAPPER_BEAN_NAME_KEY + "\"
not set. Using default : \"" + DEFAULT_WRAPPER_MBEAN_NAME + "\"");
            name = DEFAULT_WRAPPER_MBEAN_NAME;
        }
        return name;
    }
}




This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.

Re: [Wrapper-user] question about quotes in path

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

Haig,
    The .stripquotes suffixes are only used on UNIX versions of the 
Wrapper.  They
make it possible create cross platform wrapper configuration files.   
See the docs
for wrapper.java.additional.x for a more detailed explanation.

    If I understand correctly, the value of the PATH environment 
variable actually
contains " characters on your system?   What application is doing that?  
I would expect
that to break a number of applications, not just the Wrapper.   As a 
rule, the PATH
environment variable should not itself contain quotes.   It is very 
common for batch
files to add their own quotes around PATH or other environment variable 
values.

Cheers,
Leif

Haig Ehramdjian wrote:

>Hello,
>
>I've noticed in a couple of places that you have a .stripquotes
>
>wrapper.java.additional.1=-Xrs
>wrapper.java.additional.2=-Dprop=TRUE
>wrapper.java.additional.3=-Dmyapp.data="../data"
>wrapper.java.additional.3.stripquotes=TRUE
>
>Would this work in the following scenario?
>
>wrapper.java.library.path.1=../lib1
>wrapper.java.library.path.2=../lib2
>wrapper.java.library.path.3=../lib3
>wrapper.java.library.path.append_system_path=true
>wrapper.java.library.path.stripquotes=true
>
>Some applications installed on certain Win32 machines put quotes in the
>PATH.
>This, in turn, prevents my application from running.
>  
>