ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Basel Ahmed <B06...@FDS.com>
Subject RE: problem with exec & rsh
Date Wed, 14 Jan 2004 22:05:22 GMT
Hi,

Thanks for the prompt reply.

Actually I use RSH not rsync.  With rsh, I am able to invoke the wsadmin 
program to install the
ear based on a JACL script.

The problem I have using ssh, is the account being used to run WebSphere 
is one that does 
not permit direct logins, even through SSH.  RSH is my way of getting 
around that limitation.

Basel Ahmed
Federated Systems Group
Site Build & Launch (Duluth)
basel.ahmed@fds.com
678-474-3203



"Anderson, Rob (Global Trade)" <Rob.Anderson2@nike.com> 
01/14/2004 04:57 PM
Please respond to
"Ant Users List" <user@ant.apache.org>


To
"Ant Users List" <user@ant.apache.org>
cc

Subject
RE: problem with exec & rsh






Does the rsync command you are trying to run behave the same way if you 
run it from the command line? I think I have seen this behavior from rsync 
before. I think you might be better off trying a different strategy than 
calling rsync from the <exec> task. I have automated a deployment similar 
to the one you describe, where an ear is build on one machine and then 
deployed to another. I would do the following:

1. Build the ear/war.
2. Tar is up with <tar>
3. Scp it to the remote server with <scp>
4. Use <sshexec> to connect to the remote server and do the following:
                 a. stop the appserver
                 b. backup the existing ear/war (delete the previous 
backup first)
                 c. untar the new ear/war
                 d. move the new ear/war into place
                 e. start the appserver

This strategy provides you with the ability to quickly and easily backout 
the changes if necessary.

I hope this helps,

-Rob Anderson

-----Original Message-----
From: Basel Ahmed [mailto:B06BSA@FDS.com]
Sent: Wednesday, January 14, 2004 1:39 PM
To: user@ant.apache.org
Subject: problem with exec & rsh


Hello,

I have a problem with rsh called through the ant exec directive not 
terminating properly.

Synopsis:

I have an ant script that handles building the application ear file on a 
build server.  Upon
successfully completing the build tasks, it then calls a deploy task which 

attempts to install
the ear to a remote server using ant's <exec> directive and the Unix rsh 
command.

Problem:

>From all indications, the scripts are called properly and the remote 
deploy does in fact 
complete successfully, however the rsh process does not terminate. 
Furthermore, it looks
like a second rsh process is being spawned by the first one as indicated 
by the process id
(the process id for rsh process #2 has a parent process number of rsh 
process #1).

My Questions:

1 -  Has anyone else experienced this and if so, is there a known 
resolution?

2 -  What could be resulting in the second rsh process being spawn and 
does anyone have
any suggestions on how I can further debug this issue?

3 - Can anyone offer some insight into a better way of doing the same 
thing and possibly
in a more robust manner?

Below is the specific task responsible for the remote deploy:

<!-- 
====================================================================== -->
<!-- Target Name: remotedeploy  -->
<!-- 
====================================================================== -->
<target name="remotedeploy"
        description="Deploy EAR package"
        depends="transfer" >

  <echo message="Deploying fedad${build.name}.ear copied to: 
${deploy.to.server} " />
  <exec executable="/usr/bin/rsh">
     <arg line="${deploy.to.server} -l fsgapp &quot;scripts/deploy.sh 
fedad${build.name}.ear&quot;" />
  </exec>

  <exec executable="bin/deploy_notify.sh">
     <arg line="fedad${build.name}.ear ${deploy.to.server}" />
  </exec>

</target>


Thanks in advance!


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message