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

External task only runs in a nested workflow

pbenn

I'm seeing a peculiar problem. I have an external perl task (a modified version of iwsend_mail.ipl) that runs successfully from the command line. However, I can only get it to run from a nested workflow. When called from the parent workflow, it runs (I can see a few log messages) but then it simply stops. The line where it is failing is inoccuous enough, containaing a call via back ticks to the CLT, iwconfig. The call never retuns. Note that in the same instance of the script, the CLT returns successfully.

As I said, if I then run the script manually with the correct job and task ids, the workflow continues on to completion, including calling the _same_ script again with the _same_ arguments in a nested workflow.

I can provide more details, but I thought I'd fish for any further ideas first.

Thanks,

Peter

Find more posts tagged with

Comments

james1

What version of TeamSite?

Solaris, Windows, or something else?

What users own the tasks in the parent and nested jobs?

-- James

--
James H Koh
Interwoven Engineering

pbenn

TS 6.1.0 Build 33333
Solaris 5.8
Owner parent task - me (admin role)
Owner nested task - someone else (not root) (master role)

Note that the script runs in both tasks, it just 'stops' part way through in the parent task

Adam Stoller

How are you determining that the script stops / hangs on an iwconfig call?
If you're doing so based on an "error" message about no such variable debug_output (or some such) - that's probably a red herring - it simply means there's no such variable defined in your iw.cfg file so when it's requested with iwconfig it spews out an error message.

In order to determine where the script is really hanging - you'd need to probably add a lot more debugging statements into the code to track it.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

james1

What makes you think that it is the parent-ness or nested-ness that is making the script succeed or fail? Could it have anything to do with the tasks' ownership?

-- James

--
James H Koh
Interwoven Engineering

pbenn

I know it is hanging because I output a log statement around the suspected hang point after every line. The log clearly stops and the task never completes. The rub is, the subroutine where the hang occurs executes successfully 5 or so times before the hang.

I've set $| =1 to force immediate flushing of the log file handle.

If I eliminate the line with back ticks and just hard code the value, everything continues on as normal until I hit a DBI database connect call where the same thing happens. The log just stops. I've checked the integrity of the database and tested DBI in a standalone script. All came back okay.

Is there any way to obtain information on interwoven processes (like run state)? I suppose I could obtain the process id within the script itself and do a ps on it. Is there a better way?

Thanks

P.

pbenn

I don't know for sure if the parent-ness is an issue, but here's what I observed:

1) Script hangs (it starts execution, then just stops) in parent workflow
2) I manually run the script with the same args. It sets the calllback and calls exit(0)
3) The workflow continues, enters the nested workflow and calls the same script. This time, it executes to completion

I suspected it was a task ownership issue, but that would mean that the script would never start, correct? I'm definitely seeing the script start execution.

Thanks,

P.

james1

> I suspected it was a task ownership issue, but that
> would mean that the script would never start, correct?

No.

On Solaris, the external task program runs as the user that owns the task. Therefore, the program could flake out at any time, due to any number of reasons, such as file permissions (i.e., user A can write to a file that the program wants to write to, but user B cannot).

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering

james1

> If I eliminate the line with back ticks and just hard code
> the value, everything continues on as normal until I hit a
> DBI database connect call where the same thing happens.

Database-related calls often involve environment variables, which are often very different in an external task environment versus an interactive command-line environment. If you haven't already, you should investigate this.

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering

pbenn

When I run the script manually as the same user (me) as owns the task, it works fine. Also, as I said in other threads, the same code executes repeatedly (in the same process) before it just flakes out. Given it is in a backtick command calling a CLT, I would expect it to return, even if the CLT failed to execute.

Thanks,

P.

pbenn

Yeah, I checked the ORACLE_HOME environment variable. It is set within a BEGIN block at the start of the file. Everything else (SID/password) is in the file

P.

John742

Just curious: When you tested the CLT and it returned successful, did you just call the ipl from a command line or did you create a test perl script with a backtick command to call the CLT?

John_Dagenhardt@dom.com

pbenn

Good point ... tried it both ways, they both worked.