%GTM-E-JOBFAIL error that I don't understand.
kdt...@gmail.com
Specifically, I am not sure where the documentation for GT.M errors
is. It is not in my GTM programmer manual.
There error occurs in this code:
SVRINIT(OUT) ;
;"Purpose: RPC entry point to turn on GTM subprocess
;"Input: OUT -- PASS BY REFERENCE. An OUT PARAMETER.
See Output docs below
;"Results: None
;"Output: 1^Success^SubGTMControllerJobNum or
-1^ErrorMessage
;"NOTE: the JOB number for the controller process will
be stored at:
;" ^TMG("TMP","SUBGTM",$J,"CONTROLLER JOB")=$ZJOB
NEW RESULT,LASTLINE,DONE,COUNT
DO CLEANJBS ;"clean up any dead jobs.
IF $GET(^%ZOSF("TMG SUB GTM"))="" DO GOTO SIDN
. SET OUT="-1^%ZOSF(""TMG SUB GTM"") not setup. Please
ask IT Administrator to run SETUP^TMGKERN3."
JOB CTRLSGTM(DUZ)
SET ^TMG("TMP","SUBGTM",$J,"CONTROLLER JOB")=$ZJOB
SET OUT="1^Success^"_$ZJOB
SET COUNT=0,DONE=0
HANG .5
...
And the specific error is at the line: JOB CTRLSGTM(DUZ)
I found this thread:
http://www.mail-archive.com/hardhats...@lists.sourceforge.net/msg04393.html
The code in CTRLSGTM(DUZ) tries to open a pipe to a GT.M subprocess,
and uses that for it's IO channel. If that process fails, would that
cause this JOBFAIL error?
Kevin
P.s.: here is the first part of the code being called.
CTRLSGTM(TMGDUZ) ;"Control Subprocess for GTM
;"Purpose: to launch a subprocess which runs GTM, with
its IO
;" redircted into this process. The ultimate
goal will
;" be for process to be controlled remotely,
via RPC link
;"Input: TMGDUZ -- PASS BY VALUE. The IEN of the
current user
;"Output: ^TMG("TMP","SUBGTM",$J,"O",Line#) will store
the output of the subprocess
;" ^TMG("TMP","SUBGTM",$J,"O",Line#) will buffer
the input to be sent to subprocss
;"NOTE: Special commands supported:
;" #BYE# -- causes the process to disconnect and
quit the subprocess.
;" #OPTION#^1234 -- Causes menu OPTION of
IEN=1234 (for example) to be
;" launched, unless disallowed in
file 227012.
KILL ^TMG("TMP","SUBGTM",$J)
DO SETUPSUB(TMGDUZ) ;Establish DUZ array for this
process
NEW GTM SET GTM="subGTM"
NEW GTMOUT,GTMIN,TMGCMD,LINECT
SET TMGCMD=$GET(^%ZOSF("TMG SUB GTM"))
IF TMGCMD="" DO GOTO CTRDN
. SET LINECT=+$ORDER(^TMG("TMP","SUBGTM",
$J,"FROMSUB","@",-1))
. SET ^TMG("TMP","SUBGTM",$J,"FROMSUB",LINECT
+1)="Error: ^%ZOSF(""TMG SUB GTM"") not set up. Please ask IT
Administrator to run SETUP^TMGKERN3"
OPEN GTM:(COMMAND=TMGCMD:STREAM:NOWRAP)::"pipe"
USE GTM
SET ^TMG("TMP","SUBGTM",$J,"SUB-$J")=$KEY
HANG 0.200
WRITE "SET $ZPROMPT=""SUBGTM>""" ;"Set prompt
NEW DONE SET DONE=0
FOR DO QUIT:$ZEOF!DONE
. READ GTMOUT:1
. IF (GTMOUT'="")&($ZA'=9) DO
. . IF GTMOUT="SUBGTM>" DO
...
kdt...@gmail.com
the code by hand, there is no error. So it seems like a permissions
issue.
But I still want to understand what kinds of problems will cause a
JOBFAIL error.
Kevin
K.S. Bhaskar
http://fis-gtm.com and click on the User Documentation tab. That page
lists all current documentation as well as links to mirrors.
For the GTM-E-JOBFAIL error message, you should look at the Messages and
Recovery Procedures manual. JOBFAIL is listed there.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________
kdt...@gmail.com
Thank you for your reply(s).
Here is the description of that error:
=================
JOBFAIL, JOB command failure
Run Time Error: This indicates that a JOB command did not complete
successfully.
Action: Review the accompanying message(s) for additional information.
If a STARTUP jobparameter is specified, make sure that the file is
accessible and has the desired content.
...
===================
I am going to try to get more info from the variable table as stored
in ^XTER.
But I think this is a permissions issue still.
Bhaskar, you posted once that creating a pipe to a linux process is a
different process than doing ZSYSTEM. In the system I am working on,
the user can't use ZSYSTEM because the user is not set up to be able
to get to a shell. Is it possible that in fact that this the same
problem--not being able to get a shell? My pipe command is to run sh
(shell) with a script name. Would it work it directly launched an
executable file?
This is fairly arcane stuff. If you don't have a ready answer, I can
take this to the support list on hardhats.
Thanks again.
Kevin
On Sep 7, 10:24 am, "K.S. Bhaskar" <ks.bhas...@fisglobal.com> wrote:
> All current GT.M user documentation is on the web. Go tohttp://fis-gtm.comand click on the User Documentation tab. That page
K.S. Bhaskar
does not prevent the process from using a pipe. But you may have to
explicitly tell the OPEN command to use /bin/sh as the shell.
GTM>zsy "ls"
GTM>zsy
GTM>o "uptime":(SHELL="/bin/sh":COMMAND="uptime":READONLY)::"PIPE"
GTM>for use "uptime" read x quit:$zeof use $principal write x,!
12:59:59 up 4:03, 1 user, load average: 0.62, 0.63, 0.73
GTM>use $principal write $ztrnlnm("SHELL")
/bin/false
GTM>
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
skip ormsby
K.S. Bhaskar
I just used uptime as an example! It could be any process. Kevin asked
whether setting $SHELL to /bin/false to block ZSYSTEM also blocked PIPE
devices, and the answer is no, it does not. That's all I was attempting
to illustrate.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 09/07/2010 01:58 PM, skip ormsby wrote:
> Silly question Kevin - why not use %ZTLOAD/TaskMan?
>
> On Tue, Sep 7, 2010 at 1:04 PM, K.S. Bhaskar <ks.bh...@fisglobal.com
> <mailto:ks.bh...@fisglobal.com>> wrote:
>
> Setting the SHELL environment variable to /bin/false to block
> ZSYSTEM does not prevent the process from using a pipe. But you may
> have to explicitly tell the OPEN command to use /bin/sh as the shell.
>
> GTM>zsy "ls"
>
> GTM>zsy
>
> GTM>o "uptime":(SHELL="/bin/sh":COMMAND="uptime":READONLY)::"PIPE"
>
> GTM>for use "uptime" read x quit:$zeof use $principal write x,!
> 12:59:59 up 4:03, 1 user, load average: 0.62, 0.63, 0.73
>
> GTM>use $principal write $ztrnlnm("SHELL")
> /bin/false
> GTM>
>
>
> Regards
> -- Bhaskar
>
> GT.M - Rock solid. Lightning fast. Secure. No compromises.
>
> On 09/07/2010 12:17 PM, kdt...@gmail.com <mailto:kdt...@gmail.com>
> <mailto:ks.bhas...@fisglobal.com>> wrote:
> > All current GT.M user documentation is on the web. Go
> tohttp://fis-gtm.comand click on the User Documentation tab.
> That page
> > lists all current documentation as well as links to mirrors.
> >
> > For the GTM-E-JOBFAIL error message, you should look at the
> Messages and
> > Recovery Procedures manual. JOBFAIL is listed there.
> >
> > Regards
> > -- Bhaskar
> >
> > GT.M - Rock solid. Lightning fast. Secure. No compromises.
> >
> > On 09/07/2010 09:11 AM, Nancy Anthracite wrote:
> >
> >
> >
> >
> >
> > > I am sure it is online somewhere, but here is an old pdf of an
> error manual
> >
> > > On Tuesday, September 07, 2010, kdt...@gmail.com
> <mailto:Hardhats%2Bunsu...@googlegroups.com>
> >
> > _____________
> >
> > The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i)
> delete
> the message and all copies; (ii) do not disclose, distribute or
> use the
> message in any manner; and (iii) notify the sender immediately. In
> addition, please be aware that any message addressed to our
> domain is
> subject to archiving and review by persons other than the intended
> recipient. Thank you.
> > _____________
>
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to
> Hardhats+u...@googlegroups.com
> <mailto:Hardhats%2Bunsu...@googlegroups.com>
>
>
> _____________
>
> The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i)
> delete the message and all copies; (ii) do not disclose, distribute
> or use the message in any manner; and (iii) notify the sender
> immediately. In addition, please be aware that any message addressed
> to our domain is subject to archiving and review by persons other
> than the intended recipient. Thank you.
> _____________
>
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
> <mailto:Hardhats%2Bunsu...@googlegroups.com>
skip ormsby
kdt...@gmail.com
I think that Taskman is ideal for running a background task at
scheduled intervals. My background task stays active for as long as
it is communicating with the sub-gtm process via pipe. I could use
Taskman to launch the job when needed, but it is no bother for me to
launch it myself.
Part of my question was what triggered the JOBFAIL error **in the
parent task**. I would not have expected that to be reflected back to
the parent task. For example, imaging that Task A jobs off a process
(Task B) that runs for 2 days before encountering some sort of error.
Is that error in Task B going to THEN trigger an error state in Task
A? I would expect that Task B would crash etc, but not affect the
parent. What if the parent has stopped execution prior to the error
being found?
So in my case, my Task B tries to open a pipe. And I suspect that is
causing a problem for the issues mentioned in prior posts. So I would
understand if task B failed. But I was surprised to get a message back
in CPRS about the JobFail via "Task A".
Kevin
On Sep 7, 2:33 pm, skip ormsby <skip.orm...@gmail.com> wrote:
> Right Bhaskar, but his original question was about the Jobbing, but you can
> use %ZTLOAD and let TaksMan sweat the small stuff.
>
>
>
>
> > Skip --
>
> > I just used uptime as an example! It could be any process. Kevin asked
> > whether setting $SHELL to /bin/false to block ZSYSTEM also blocked PIPE
> > devices, and the answer is no, it does not. That's all I was attempting to
> > illustrate.
>
> > Regards
> > -- Bhaskar
>
> > GT.M - Rock solid. Lightning fast. Secure. No compromises.
>
> > On 09/07/2010 01:58 PM, skip ormsby wrote:
>
> >> Silly question Kevin - why not use %ZTLOAD/TaskMan?
>
> >> <mailto:Hardhats%2Bunsu...@googlegroups.com<Hardhats%252Bunsubscribe@go oglegroups.com>
> >> > _____________
>
> >> > The information contained in this message is proprietary and/or
> >> confidential. If you are not the intended recipient, please: (i)
> >> delete
> >> the message and all copies; (ii) do not disclose, distribute or
> >> use the
> >> message in any manner; and (iii) notify the sender immediately. In
> >> addition, please be aware that any message addressed to our
> >> domain is
> >> subject to archiving and review by persons other than the intended
> >> recipient. Thank you.
> >> > _____________
>
> >> --
> >> http://groups.google.com/group/Hardhats
> >> To unsubscribe, send email to
> >> <mailto:Hardhats%2Bunsu...@googlegroups.com<Hardhats%252Bunsubscribe@go oglegroups.com>
> >> _____________
>
> >> The information contained in this message is proprietary and/or
> >> confidential. If you are not the intended recipient, please: (i)
> >> delete the message and all copies; (ii) do not disclose, distribute
> >> or use the message in any manner; and (iii) notify the sender
> >> immediately. In addition, please be aware that any message addressed
> >> to our domain is subject to archiving and review by persons other
> >> than the intended recipient. Thank you.
> >> _____________
>
> >> --
>
>
> read more »
OldMster
Bhaskar will hopefully correct me if I'm wrong, but I would expect the
Jobfail error only if the parent was unable to successfully create the
new job, not if the 'jobbed' process subsequently had an error. I've
never tried jobbing a subroutine line, so I don't know if that is even
supposed to work. Have you tried doing the Job command with the full
routine reference instead of just the subroutine call? ie JOB
CTRLSGTM^theroutinename(DUZ)?
Mark
>
> read more »
kdt...@gmail.com
the steps that lead to this crazy error.
1. Putty connects to cloud server, and creates a tunnel for port 9260
2. CPRS connects to server through tunnel.
3. xinetd.d contains a file: vista_9260-client-xwb that looks like
this. Notice that I made the user to be root, so there is no question
of a permissions issue:
service vista_EHR_client
{
port = 9260
socket_type = stream
protocol = tcp
user = root
server = /opt/worldvista/EHR/bin/vista_client-port-xwb.sh
type = UNLISTED
wait = no
disable = no
groups = yes
}
4. CPRS then calls a RPC which calls SVRINIT^TMGKERN3(OUT) This call
does take place normally, and returns valid results. That is to say
it did before I put a test crash line in (see below). Here is a
highly modified version of the code that is creating errors:
SVRINIT(OUT) ;
;"Purpose: RPC entry point to turn on GTM subprocess
;"Input: OUT -- PASS BY REFERENCE. An OUT PARAMETER.
See Output docs below
;"Results: None
;"Output: 1^Success^SubGTMControllerJobNum or
-1^ErrorMessage
;"NOTE: the JOB number for the controller process will
be stored at:
;" ^TMG("TMP","SUBGTM",$J,"CONTROLLER JOB")=$ZJOB
JOB KILLTHIS ;"REMOVE LATER!
;
here is the function 'KILLTHIS'
KILLTHIS ;
HANG 60
QUIT
5. Here is the error I get from CPRS when I try to call this. I will
show the error from ^XTER.
------------------------------------------------------------------------------------------
GTM>do ^XTER
In response to the DATE prompt you can enter:
'S' to specify text to be matched in error or routine name
1 error logged on 9/12/2010
1) <(JOBFAIL)>SVRINIT+8^TMGKERN3 22:55:22 EHR,EHR 13450 /dev/
null
No screened error
Enter '^' to quit listing, <RETURN> to continue...: 1
Process ID: 13450 (13450) SEP 12, 2010 22:55:22
UCI/VOL: [EHR,EHR]
$ZA: 0
Current $IO: /dev/null Current $ZIO: /dev/null^0^0^0
$ZE= SVRINIT+8^TMGKERN3, JOB command failure,150373114,-%GTM-E-JOBFAIL
JOB KILLTHIS ;"REMOVE LATER!
Last Global Ref: ^XUSEC("XUPROGMODE",14)
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
I will include the variable table below. Can anyone tell me a valid
reason why the JOB command would be failing?? I feel like I am living
in the twilight zone!
Kevin
Here is the variable table.
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
$DEVICE=
$ECODE=,Z150373114,
$ESTACK=9
$ETRAP=D ^%ZTER,EXIT^XWBTCPM HALT
$QUIT=0
$STACK=9
$STACK(000)=-run GTMLNX^XWBTCPM
$STACK(000,"ECODE")=
$STACK(000,"PLACE")=RESTART+3^XWBTCPM
$STACK(000,"MCODE")= U XWBTDEV D MAIN
$STACK(001)=DO
$STACK(001,"ECODE")=
$STACK(001,"PLACE")=MAIN+1^XWBTCPM
$STACK(001,"MCODE")= F D Q:XWBTBUF="#BYE#"
$STACK(002)=DO
$STACK(002,"ECODE")=
$STACK(002,"PLACE")=MAIN+14^XWBTCPM
$STACK(002,"MCODE")= . D CALLP^XWBPRS(.XWBR,$G(XWBDEBUG)) ;Read the
NEW Msg para
meters and call RPC
$STACK(003)=DO
$STACK(003,"ECODE")=
$STACK(003,"PLACE")=CALLP+10^XWBPRS
$STACK(003,"MCODE")= I '+ERR D
$STACK(004)=DO
$STACK(004,"ECODE")=
$STACK(004,"PLACE")=CALLP+11^XWBPRS
$STACK(004,"MCODE")= . D CAPI(.XWBP,XWB("PARAM"))
$STACK(005)=DO
$STACK(005,"ECODE")=
$STACK(005,"PLACE")=CAPI+10^XWBPRS
$STACK(005,"MCODE")= D @XWBCALL S XWBCALL2=XWBCALL ;Save call for
debug
$STACK(006)=DO
$STACK(006,"ECODE")=,Z150373114,
$STACK(006,"PLACE")=SVRINIT+8^TMGKERN3
$STACK(006,"MCODE")= JOB KILLTHIS ;"REMOVE LATER!
$STACK(007)=DO
$STACK(007,"ECODE")=
$STACK(007,"PLACE")=ETRAP+6^XWBTCPM
$STACK(007,"MCODE")= D ^%ZTER ;%ZTER clears $ZE and $ZCODE
$X $Y=0 0
$ZV=GT.M V5.4-001 Linux x86
%DT=T
%ZT("^XUTL(""XQ"",$J)")=
%ZTER11I=EHR,EHR
%ZTER11N=1
%ZTER11S=
%ZTER11Z=0
%ZTER12A=0
%ZTER12B=
%ZTERCNT=49
%ZTERH1=61981
%ZTERROR=
%ZTERRT=^%ZTER(1,61981,1,1)
%ZTERSUB=%ZTER11S)
%ZTERVAP=%ZT(
%ZTERVAR=%ZTERVAR
%ZTERZE=SVRINIT+8^TMGKERN3, JOB command failure,150373114,-%GTM-E-
JOBFAIL
DA(1)=6
DILOCKTM=3
DISYS=19
DT=3100912
DTIME=3600
DUZ=14
DUZ(0)=@
DUZ(1)=
DUZ(2)=67
DUZ("AG")=E
DUZ("AUTO")=1
DUZ("BUF")=1
DUZ("LANG")=
ERR=0
I=
IO=/dev/null
IO(0)=/dev/null
IO(1,"/dev/null")=
IO("CLNM")=it.tmg.intranet
IO("ERROR")=
IO("GTM-IP")=127.0.0.1
IO("HOME")=47^/dev/null
IO("IP")=xxx.xxx.xxx.xxx <-- removed. Let me know if needed
IO("ZIO")=/dev/null
IOBS=$C(8)
IOF=#
IOHG=
IOM=132
ION=
IOPAR=
IOS=0
IOSL=64
IOST=P-OTHER
IOST(0)=16
IOT=TRM
IOUPAR=
IOXY=
J=
ORWCLVER=1.0.26.69
POP=0
TYPE=1
U=^
X=5;DIC(4.2,
XPARSYS=5;DIC(4.2,
XQCY0=OR CPRS GUI CHART^CPRSChart version 1.0.26.69^^B^1^^^^^^^
XQMES=1
XQVOL=EHR
XQXFLG=0^0
XQXFLG("LLOG")=3100912.222513
XQXFLG("ZEBRA")=3100912.225516~0
XQY=8552
XQY0=OR CPRS GUI CHART
XR=[XWB]
XUCI=EHR
XUDEV=0
XUENV=EHR^EHR^labtest1^EHR:labtest1
XUF=2
XUF(.1)=
XUF(.2)=0
XUF(.3)=14
XUFAC=0
XUIOP=
XUVOL=EHR^^256^^^nXWB(0,"LENV")=3
XWB(0,"RT")=0
XWB(0,"TYPE")=1
XWB(0,"VER")=1
XWB(2,"RNAM")=TMGKERN3
XWB(2,"RPC")=TMG CONSOLE INITIATE
XWB(2,"RTAG")=SVRINIT
XWB(2,"VER")=0
XWB(5,"XWB",0)=
XWB("PARAM")=
XWBAPVER=0
XWBCALL=SVRINIT^TMGKERN3(.XWBY)
XWBCALL2=
XWBCLMAN=IT.tmg.intranet
XWBDEBUG=0
XWBENVL=3
XWBERC=SVRINIT+8^TMGKERN3, JOB command failure,150373114,-%GTM-E-
JOBFAIL
XWBERR=M ERROR=SVRINIT+8^TMGKERN3, JOB command failure,150373114,-
%GTM-E-JOBFAI
L\013\010LAST REF=^XUSEC("XUPROGMODE",14)
XWBERROR=
XWBNULL=/dev/null
XWBOS=GT.M
XWBPRT=0
XWBPTYPE=1
XWBRBUF=
XWBSEC=
XWBT("BF")=#
XWBT("PCNT")=1
XWBTBUF=
XWBTCMD=
XWBTDEV=0
XWBTIME=800
XWBTIME(1)=5
XWBTIP=206.180.153.11
XWBTSKT=0
XWBVER=1.108
XWBWRAP=0
Y=D ^ENTIRN
^XUTL("XQ",$J,0)=3100912.225516
^XUTL("XQ",$J,"DUZ")=14
^XUTL("XQ",$J,"DUZ(0)")=@
^XUTL("XQ",$J,"DUZ(1)")=
^XUTL("XQ",$J,"DUZ(2)")=67
^XUTL("XQ",$J,"DUZ(AG)")=E
^XUTL("XQ",$J,"DUZ(AUTO)")=1
^XUTL("XQ",$J,"DUZ(BUF)")=1
^XUTL("XQ",$J,"DUZ(LANG)")=
^XUTL("XQ",$J,"IO")=/dev/null
^XUTL("XQ",$J,"IO(""CLNM"")")=it.tmg.intranet
^XUTL("XQ",$J,"IO(""IP"")")=xxx.xxx.xxx.xxx <-- removed. Let me know
if needed
^XUTL("XQ",$J,"IOBS")=$C(8)
^XUTL("XQ",$J,"IOF")=#
^XUTL("XQ",$J,"IOM")=132
^XUTL("XQ",$J,"ION")=
^XUTL("XQ",$J,"IOPAR")=
^XUTL("XQ",$J,"IOS")=0
^XUTL("XQ",$J,"IOSL")=64
^XUTL("XQ",$J,"IOST")=P-OTHER
^XUTL("XQ",$J,"IOST(0)")=16
^XUTL("XQ",$J,"IOT")=TRM
^XUTL("XQ",$J,"IOUPAR")=
^XUTL("XQ",$J,"IOXY")=
^XUTL("XQ",$J,"XQVOL")=EHR
$ZE= SVRINIT+8^TMGKERN3, JOB command failure,150373114,-%GTM-E-JOBFAIL
JOB KILLTHIS ;"REMOVE LATER!
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
Dave Gifford
K.S. Bhaskar
Sorry, I have been buried and only now have a chance to think about this.
To troubleshoot, give the JOB'd process explicit STDOUT and STDERR and
see if there is anything in either of them. Also, when starting up the
server process, in /opt/worldvista/EHR/bin/vista_client-port-xwb.sh, try
explicitly redirecting STDERR to a file that you can examine later.
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 09/12/2010 07:11 PM, kdt...@gmail.com wrote:
> OK. I am out of ideas about how to figure this out. Let me spell out
> the steps that lead to this crazy error.
[KSB] <...snip...>
kdt...@gmail.com
Will do. Just a quick update on progress so far.
1. We installed my KIDS patches on an older version of Astronaut and
it works just fine.
2. We updated the GT.M ver 5.3 in the old (working) Astronaut to 5.4,
and that didn't induce error.
3. This error has occurred on more than one machine with the new
Astronaut.
4. Again, the error only seems to occur when coming in through the
xinetd method. We can't induce the error when starting the code from
a GTM> prompt.
5. We thought this might be a SE linux problem, but we installed the
new Astronaut on an Ubuntu instance, and we got the same error, so
that wasn't it.
Conclusions, the JOB command does something during the process of
creating a new process, and there is a permission issue set
somewhere. But what confuses me is that I set the xinetd user to be
root, and that didn't help. I don't know how linux regulates the
creation of new processes.
We are just stuck, not knowing where to look.
Any suggestions would be greatly appreciated.
Kevin
K.S. Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 09/16/2010 07:25 PM, kdt...@gmail.com wrote:
> Bhaskar,
>
> Will do. Just a quick update on progress so far.
[KSB] Hopefully the .mjo and .mje files of the JOB command will give
useful information.
> 1. We installed my KIDS patches on an older version of Astronaut and
> it works just fine.
> 2. We updated the GT.M ver 5.3 in the old (working) Astronaut to 5.4,
> and that didn't induce error.
> 3. This error has occurred on more than one machine with the new
> Astronaut.
> 4. Again, the error only seems to occur when coming in through the
> xinetd method. We can't induce the error when starting the code from
> a GTM> prompt.
> 5. We thought this might be a SE linux problem, but we installed the
> new Astronaut on an Ubuntu instance, and we got the same error, so
> that wasn't it.
>
> Conclusions, the JOB command does something during the process of
> creating a new process, and there is a permission issue set
> somewhere. But what confuses me is that I set the xinetd user to be
> root, and that didn't help. I don't know how linux regulates the
> creation of new processes.
[KSB] If something is failing as root, there is the probability that the
directory path doesn't exist. For example, if you define something as
$abc/$def/$ghi/jkl, and if any of the environment variables doesn't
exist, then even a root process will not create a directory where one
doesn't exist.
For example, inetd/xinetd doesn't set $HOME, IIRC. So if your global
directory defines the path to a database file as $HOME/vista.dat and
$HOME doesn't exist, you will get an error - which the error handler
should trap, but I think VistA error handling is less than wholesome
because it uses a mish-mash of standard $ETRAP error handling and MUMPS
platform specific $ZTRAP (which is not the same between GT.M and another
MUMPS implementation).
This is actually one of those situations when the Serenji debugger may be
useful. Unlike traditional debuggers where you reach into the process to
debug it, in Serenji the process calls out to a listener on a client PC.
George James offers free 30 day trial licenses for Serenji as I recall.
I wish I could be more helpful.
Regards
-- Bhaskar
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
_____________
Eddie Hagood
this TMGKERN3.mjo file. As per your last post, is there a missing
path? What would be the default directory for this to be created?
We'll look into missing directory variables.
%GTM-E-SETECODE, Non-empty value assigned to $ECODE (user-defined
error trap)
At M source location BREAD+13^XWBRW
%GTM-E-INVCMD, Invalid command keyword encountered
cd /
^-----
%GTM-E-INVCMD, Invalid command keyword encountered
ls
^-----
Tue Sep 14 14:46:09 UTC 2010
Tue Sep 14 14:46:44 UTC 2010
Tue Sep 14 14:47:37 UTC 2010
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Error redirecting stdout (creat) to TMGKERN3.mjo
%SYSTEM-E-ENO13, Permission denied
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Failed to set STDIN/OUT/ERR for the job
Tue Sep 14 14:52:36 UTC 2010
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Error redirecting stdout (creat) to TMGKERN3.mjo
%SYSTEM-E-ENO13, Permission denied
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Failed to set STDIN/OUT/ERR for the job
Tue Sep 14 15:05:20 UTC 2010
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Error redirecting stdout (creat) to TMGKERN3.mjo
%SYSTEM-E-ENO13, Permission denied
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Failed to set STDIN/OUT/ERR for the job
Tue Sep 14 15:07:05 UTC 2010
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Error redirecting stdout (creat) to TMGKERN3.mjo
%SYSTEM-E-ENO13, Permission denied
%GTM-E-JOBFAIL, JOB command failure
%GTM-I-TEXT, Failed to set STDIN/OUT/ERR for the job
Tue Sep 14 16:56:28 UTC 2010
kdt...@gmail.com
#!/bin/sh
#vista_client-port.sh: This is a file to run RPCBroker as a Linux
service
#
#scriptpath="`dirname $0`"
#cd $scriptpath
#echo "pwd: `pwd` arg0: $0"
#. ./env
# For some reason source the word won't work but period does.
. /opt/worldvista/EHR/etc/env.worldvista
#make sure of our directory
cd $gtm_vista
date >> $gtm_vista/log/vista_$vista_instance-client.log
#Run routine
# If IPv6 fff stuff, strip it out.
export REMOTE_HOST=`echo $REMOTE_HOST | sed 's/::ffff://'`
$gtm_dist/mumps -run GTMLNX^XWBTCPM 2>>$gtm_vista/log/vista_
$vista_instance-client.log
#
And here is the environment file. We added a declared home directory
and it didn't seem to make any difference. We changed the xinetd user
back to worldvistaEHR, and set the permissions for this folder to
allow anyone to use.
#!/bin/bash
# Group that needs to be changed if relocated or port changed.
export vista_instance="EHR" # Should be unique Like wvEHR or ovEHR,
training, dev.
export vista_port="9260" # Listening port for clients like
CPRS.
export vista_port_old_rpc="9210" # Listening port for old RPC.
export vista_port_vistalink="8002"
# Usually not necessary to change.
export vista_initials="wv" # Branding initials like wv or ov.
export vista_version="worldvista" # Branding such as
openvista, worldvista, vxvista.
#
export vista_path="/opt/$vista_version/$vista_instance" # Path to
this instance like /opt/worldvista/PROD.
export gtm_dist="/opt/fis-gtm/gtm" # Path to gtm such as /opt/
fis-gtm/gtm, changed to symlink in 0.7 series.
export vista_group="$vista_version$vista_instance"
export vista_owner="$vista_version$vista_instance"
export text_user="text$vista_instance" # id for text users.
Default is text$vista_instance
export client_user="client$vista_port"
HOME="/home/worldvistaEHR"
vista_parts="/usr/share/vista_parts"
# Appliance mode set to true deletes intermediate files to save
space.`
appliance_mode="0"
# These are usually NOT modified to create a new instance.
routine_file="routines.wv.tar.gz" # Prepared
routine file.
globals_file="globals.wv.tar.gz" # Prepared
globals file.
astro_vers_release="0.9-9" # Installer version.
astro_install_file="astronaut-$vista_initials-$astro_vers_release.rpm"
# deb/rpm File that installed this.
#env_file_branding="my_astro_env_file_branding"
env_file_branding_release="VOE1.0" # Such as EHR/VOE 1.0
env_file_path="$vista_path/etc/env.${vista_version}"
whereRwe="/usr/share/vista_parts"
gtm_path="/opt/fis-gtm/gtm"
export gtm_dist=$gtm_path
gtm_group="gtm"
vista_user=$vista_version$vista_instance
VISTAUSER_PASSWD="vista!123"
VISTAGROUP=$vista_version
text_user="text$vista_port"
TEXTUSER_PASSWD="not#1sostrong"
client_user="client$vista_port"
CLIENTUSER_PASSWD="not#1sostrong"
# These are usually NOT modified.
# Journal file rotation and backups.
purge_daily=1 # Purge journal files daily
yes=1 no=0
num_journals=3 # Number of journal files to
keep around.
backup_daily=1 # Backup daily yes=1 no=0
num_backups=3 # Number of backups to keep
around. 0 for do not delete backups.
# plugin variables.
export m2web="$vista_path/plugins/web/m2web"
export ewd_path="the_ewd_path"
export astronaut_version="astro_vers_release"
export astro_install_file="astro_file" # Installed from filename
export open_client_port_on_startup="1" # open=1 do not open=0
#
export vista_release="worldvista_release" # Release numbers.
export gtm_version="V5.4-0001"
export ewd_version="762"
export vsb_compliant=1
export vsb_version="0.12"
# MD5 Library external-call table
export GTMXC_md5="$vista_path/plugins/web/m2web/xc/gtm_md5.xc"
#
export vista_home="$vista_instance"
export gtm_path=$gtm_dist
export gtm_sysid="$vista_owner"
export gtm_vista="$vista_path"
export gtm_log="$vista_path/log"
export gtmgbldir="$vista_path/globals/mumps.gld"
export gtmroutines="$vista_path/objects($vista_path/patches
$vista_path/routines $vista_path/plugins/web/m2web $vista_path/plugins/
web/ewdapps/routines) $gtm_dist"
export gtm_zinterrupt="DO JOBEXAM^ZU"
alias GDE="$gtm_dist/mumps -r GDE"
alias rundown='$gtm_dist/mupip rundown -r "*"'
alias GTM="$gtm_dist/mumps -direct"
alias gtm="$gtm_dist/mumps -direct"
alias mupip="$gtm_dist/mupip"
alias gde="$gtm_dist/mumps -r ^GDE"
alias GDE="$gtm_dist/mumps -r ^GDE"
alias lke="$gtm_dist/lke"
alias dse="$gtm_dist/dse"
alias LKE="$gtm_dist/lke"
alias DSE="$gtm_dist/dse"
>
> read more »
Nancy Anthracite
try the other although I believe one is technically correct and not the other.
I believe the dot is the preferred way to do it.
--
Nancy Anthracite
K.S. Bhaskar
-- Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
David Whitten
instead of "/bin/bash" in the script started by xinetd.
I believe "source" is a command in bash and not in standard posix "sh".
Perhaps Gus Landis could give an opinion on this...
David.
LD 'Gus' Landis
> I expect that "source" doesn't work, because you are starting up /bin/sh
> instead of "/bin/bash" in the script started by xinetd.
> I believe "source" is a command in bash and not in standard posix "sh".
> Perhaps Gus Landis could give an opinion on this...
>
> David.
>
> On Fri, Sep 17, 2010 at 12:18 PM, Nancy Anthracite
> <nanth...@earthlink.net> wrote:
>> It is a mystery to me as well, but I have learned that if one does not work,
>> try the other although I believe one is technically correct and not the other.
>> I believe the dot is the preferred way to do it.
>
Hi,
I am only going to comment on the above (more on the rest of the
message later, as I dig into it).
For a bit of differences between sh and bash, the following looks ok:
http://www.cs.uleth.ca/~holzmann/C/shells/shellnotes.html
Depending on the distribution, there may be differences in the version
of sh and bash, which is a pain, but needs to be considered.
Re: "source" and "."
Historically, the command was ".", so that has the largest mind-share.
I have rarely run into differences between "." and "source" semantics,
but some shells do not recognize "source".
I have not yet "modernized" my scripting to use "source" exclusively,
but I find that people see it better than the lonely dot.
Cheers,
--ldl
--
---
NOTE: If it is important CALL ME - I may miss email,
which I do NOT normally check on weekends nor on
a regular basis during any other day.
---
LD Landis - N0YRQ - de la tierra del encanto
3960 Schooner Loop, Las Cruces, NM 88012
575-448-1763 N32 21'48.28" W106 46'5.80"
JohnLeo Zimmer
I expect that "source" doesn't work, because you are starting up /bin/sh
instead of "/bin/bash" in the script started by xinetd.
I believe "source" is a command in bash and not in standard posix "sh".
Perhaps Gus Landis could give an opinion on this...
kdt...@gmail.com
back working.
The error was that the xinetd.d specified script was leaving the
default directory as /. And when we changed it to be where it should
be, there were permissions problems there.
Lessons learned:
1. GT.M puts the .mjo files into the current directory, not a
directory specified by some variable such as HOME etc.
2. To debug the xinetd.d specified script, add a few lines like this:
id
pwd
exit
Then connect to the port directly via telnet. I.e. telnet
localhost 9260
When we did this we could tell we were in the wrong directory, and
it told us for sure who we were running as.
3. Just editing the xinetd.d files to not effect the change. When I
wrote earlier that we had changed the user to root and were still
getting the problem, I didn't realize that, so was further confused as
to why root was being denied. The "id" line above helps find that
out. To restart it, I think it is something like this:
service xinetd restart
4. It is very difficult to debug on a mailing list. There is no
substitute for fingers on the keyboard directly interacting with a
problem.
So kudo's to Gus. Thanks again! He rocks!
Kevin
K.S. Bhaskar
GT.M - Rock solid. Lightning fast. Secure. No compromises.
On 09/19/2010 07:34 PM, kdt...@gmail.com wrote:
> I am very happy to report that Gus Landis found the problem and we are
> back working.
>
> The error was that the xinetd.d specified script was leaving the
> default directory as /. And when we changed it to be where it should
> be, there were permissions problems there.
>
> Lessons learned:
>
> 1. GT.M puts the .mjo files into the current directory, not a
> directory specified by some variable such as HOME etc.
[KSB] Actually, GT.M allows you to explicitly specify the locations of
the .mje and .mjo files for STDERR and STDOUT, as well as a file for
STDIN. A minor current bug - it creates empty .mje and .mjo files in the
current directory as well, if you specify them in another directory.
<...snip...>
> 3. Just editing the xinetd.d files to not effect the change. When I
> wrote earlier that we had changed the user to root and were still
> getting the problem, I didn't realize that, so was further confused as
> to why root was being denied. The "id" line above helps find that
> out. To restart it, I think it is something like this:
> service xinetd restart
[KSB] Remember that this will require root / sudo. On Red Hat and
current Ubuntu releases. On Debian and older Ubuntu releases it would be
/etc/init.d/ssh restart.
-- Bhaskar