OpenDeploy hangs with instance

Getting a wierd problem, we are running a very simple deployment from ts server to a prod server with a filelist through a firewall. If there is no -inst attached, it works fine, but whenever -inst with some numbers is attached, it hangs. The base server is 5.6.1.0 and receiver is 5.6.0.0 on windows 2000. And the deployment is run by administrator. With the same config file it works fine to another server which has OD receiver 5.6.1.0 thourgh another firewall. Does it have anything to do with the firewalls or might be some other issue? Any help is appreciated.

the command we use is :
d:/iw-home/iw-perl/bin/iwperl.exe d:/INTERW~1/OPENDE~2/solutions/perl/iwodstart.ipl FilelistDeployment -k sourceDir=Y:/default/main/Internet/STAGING -k destDir=E:\sites\internet\docroot -k filelist=d:/INTERW~1/OPENDE~2/tmp/filelist/filelist120847111208472 -inst 120847111208472

log file and config file are attached.

Find more posts tagged with

Comments

nipper

Since you are on 5.6, which has been end of life for a while, the chances of getting this solved are slim.

From my memory, I never used the iwodstart perl script to start a WF, but I used iwod start (or was it iwodcmd start) from od-home/bin

check the bin directory and see what choices you have as executables instead of a perl script.

If you need to use the perl script, you may need to post that for anyone to remotely have a chance to debug.

Also, I am assuming that ther are no hung jobs, esp with that #. If one is running with that -inst value, the next queues up behind is.

Try iwodserverstatus (that is a 6.X command, I do not remember what, if any, was the equivalent in 5.6)

Andy

Adam Stoller

Since you are on 5.6, which has been end of life for a while, the chances of getting this solved are slim.

From my memory, I never used the iwodstart perl script to start a WF, but I used iwod start (or was it iwodcmd start) from od-home/bin

check the bin directory and see what choices you have as executables instead of a perl script.

If you need to use the perl script, you may need to post that for anyone to remotely have a chance to debug.

Also, I am assuming that ther are no hung jobs, esp with that #. If one is running with that -inst value, the next queues up behind is.

Try iwodserverstatus (that is a 6.X command, I do not remember what, if any, was the equivalent in 5.6)

Andy

I believe iwodcmd was introduced in 6.0 (I just took a look at the various 5.6 manuals I have and cannot find a mention of it there) -- if present on your system, it is the recommended CLT to use.

iwodstart.ipl was created for the 5.5.1 release after people who were using WindowsNT were complaining about the error codes not being returned correctly from the iwodstart.bat script - and it appeared to work pretty nicely for its intended audience, but I believe there were still problems with some other versions of Windows.

iwodstart.ipl was never intended to be used on Unix - though a number of people did try to do so, and I believe the script did get modified at some point to try to make it work better for people on Unix.

I don't think any of this has anything to do with the problem being reported though - the firewall, or the fact that the deployment that doesn't work is a down-rev deployment is more likely to be a potential source of issues - especially if all patches aren't applied correctly.

polotoo

Thanks for quick response. I did use iwodserverstatus and no jobs are using same instance number and they v been in running status for days , I think the only way to kill them is to restart the service.

Now we can't patch because it is a remote production server and we have no access to it. I checked the bug report of down-rev deployment, the only thing I can see is job hangs when sender is 6.0 and receiver is 5.6 without patch. There is no report for any bugs from 5.6.1.0 to 5.6.0.0. Firewall might be another cause, but why it can go through when there is no instance attached. No clues, scratch my head Smiley Sad

MAK

Hi,

There will be some receiver logs created, when you run this deployment.
Please post you receiver logs as well.