nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

issue with custom service that uses iwatupdate.ipl

btrotter

using srvany.exe to run a custom service that utilizes iwatupdate.ipl passing another perl script as a param when it sees an update event in the e:\iw-home\local\logs\iwevents.log file.

this service is running successfully on 5 other teamsite base servers currently and only recently died on one of our pilot servers for no apparent reason. there is nothing in the events logs that gives any indication of how or when it died. this server was performing successful transfers within at least a week of when this issue first arose.

basically the custom service watches for an update event in the iwevents.log and when it sees it, a teamsite trasnfer is initiated and open deploy is called to transfer content to a target server.

the process works perfectly if you open a command prompt and call iwatupate.ipl passing our custom script watchupdate.ipl and leave the command window open however it will not run like it used to as a service. the service shows running in computer management and task manager however and an instance of perl.exe and srvany.exe also show in task manager.

i've checked permissions on all folders involved and compared to servers that are working properly.

i've replaced all the files in question with fresh copies from working servers (iwatupdate.ipl, watchupdate.ipl, srvany.exe)

i've uninstalled and installed the servcie many times with many server reboots.

i've cleaned the registry, run chkdsk, run defrag.

i've compared all maintenance performed on this server to maintenance performed on another working server that is in the same maintenance cycle and they are identical.

i've enlisted autonomy support although this feels like it's related to the windows 2003 server OS.

no logs are created in the deploylogs directory after a transfer if it's running as a service however logs get created if running at the command prompt.

srvany.exe was original created in the early 90's and is known to have issues but have had no luck doing research for this issue on the internet.

has anyone else experienced anything like this? looking for ideas....fresh out here.

Find more posts tagged with

Comments

Adam Stoller

Personally I would completely scrap iwatupdate.ipl and the srvany stuff and re-implement the trigger via iwat itself (the scripts will have to change to look for information in @ARGV rather than %ENV - but other than that you shouldn't need much change).

It's cleaner and simpler IMO.

btrotter

Thanks for the reply Ghoti! I saw another post of yours with regard to iwat and started to look in to that late last week. I'll pursue that further.

btrotter

Thanks for the reply Ghoti. I have implemented the solution as you have suggested using iwat to create event handlers and was able to get some environmental variables out of @ARGV.

btrotter

Thanks for the reply Ghoti. I have implemented the solution as you have suggested using iwat to create event handlers and was able to get some environmental variables out of @ARGV.

It appears that the iwat.exe process is kept alive via the "Interwoven Utilities Daemon" service that appears in the computer management console along with some other Interwoven services. We use a tool called Operations Manager to monitor various things such as cpu usage, memory usage, and services among other things. We have it set up to send us an email alert if a service fails, attempt to restart the service, and if that fails it will send out a pager alert to whomever is on call.

Would monitoring the Interwoven Utilites Daemon service be enough in your opinion to keep tabs on any event handlers we create using iwat.exe or should we do more?

nipper

Would monitoring the Interwoven Utilites Daemon service be enough in your opinion to keep tabs on any event handlers we create using iwat.exe or should we do more?

That should be sufficient to make certain that the event handlers get *started*, but obviously will not do squat if you have a bug in the logic.

I have set up a "heartbeat" process on something that is repeatable on a schedule, just before it completes, touch a specific file and with my monitoring program I watch the update time of that file.

btrotter

That should be sufficient to make certain that the event handlers get *started*, but obviously will not do squat if you have a bug in the logic.

I have set up a "heartbeat" process on something that is repeatable on a schedule, just before it completes, touch a specific file and with my monitoring program I watch the update time of that file.

The scripts we'd be triggering have been used for years without logic changes so I'm fairly confident that as long as they are being called and iwat.exe is alive we'll be ok. They also have logging files they write to each time they are called.

Adam Stoller

The scripts we'd be triggering have been used for years without logic changes so I'm fairly confident that as long as they are being called and iwat.exe is alive we'll be ok. They also have logging files they write to each time they are called.

And when somebody, for some reason, modifies one of those files .... ?
General rule - don't ever trust code to not change (pardon the double-negative) unless it's burned into a chip - and even then....

btrotter

And when somebody, for some reason, modifies one of those files .... ?
General rule - don't ever trust code to not change (pardon the double-negative) unless it's burned into a chip - and even then....

Valid point. That's why we have test, pilot, and production environments to test code changes. A heartbeat process is not a bad idea though.