| Author |
Message
|
| exerk |
 Posted: Sun Apr 27, 2014 11:47 pm Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
What userid are you running the DLQH under from the command line, and what group(s) is it in?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
 |
| cevans |
| Posted: Sun Apr 27, 2014 11:48 pm Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
| exerk wrote: |
OK, having finally managed to dig out an 'automated' DLQH set-up, I have the following:
| Code: |
STARTCMD('/<path>/mqdlqh.sh') +
STARTARG('DEAD.LETTER.QUEUE +QMNAME+ < /<path>/<rules_file_name>') +
STDOUT('/<path>/<stdout_file_name>') +
STDERR('/<path>/<stderr_file_name>') +
CONTROL(STARTONLY) +
SERVTYPE(SERVER) |
And as mqjeff has stated, note the quotes...
The rules files contains the following:
| Code: |
* Start Control Data
RETRYINT(nn) WAIT(YES)
* End Control Data
* Start Rules
REASON(<MQRC>) ACTION(FWD) FWDQ(<QUEUE_NAME>)
REASON(<MQRC>) ACTION(RETRY) RETRY(n)
* End Rules |
Obviously you'll need to substitute the desired <MQRC> and (n) values suitable for you. |
I redefined the service and still get the same problem with the service promptly ending after initially displaying as running.
My service definition was as follows .. Does this look ok to you?
| Code: |
DEFINE SERVICE(myDLQHANDLER) +
SERVTYPE(SERVER) +
CONTROL(MANUAL) +
STARTCMD('/var/mqm/qmgrs/IB9QMGR/dlqhandler.sh') +
STARTARG('IB9QMGR.DLQ IB9QMGR </var/mqm/qmgrs/IB9QMGR/dlqhandler.rules') +
STDOUT('/var/mqm/log/IB9QMGR/dlqhandler.log') +
STDERR('/var/mqm/log/IB9QMGR/dlqhandler.err')
AMQ8625: WebSphere MQ service created.
6 : display service(MYDLQHANDLER)
AMQ8629: Display service information details.
SERVICE(MYDLQHANDLER) CONTROL(MANUAL)
SERVTYPE(SERVER)
STARTCMD(/var/mqm/qmgrs/IB9QMGR/dlqhandler.sh)
STARTARG(IB9QMGR.DLQ IB9QMGR </var/mqm/qmgrs/IB9QMGR/dlqhandler.rules)
STOPCMD( ) STOPARG( )
STDOUT(/var/mqm/log/IB9QMGR/dlqhandler.log)
STDERR(/var/mqm/log/IB9QMGR/dlqhandler.err)
DESCR( ) ALTDATE(2014-04-28)
ALTTIME(08.33.27) |
Thanks |
|
| Back to top |
|
|
| cevans |
| Posted: Mon Apr 28, 2014 5:41 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
| exerk wrote: |
| What userid are you running the DLQH under from the command line, and what group(s) is it in? |
I am running the command line as my own account cevans and the userid is in the mqm and mqbrkrs |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 28, 2014 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You might not be passing the right params to the dlqhandler
You need to be able to check (write out to the log ) from your .sh what the value of the input params are, show $1, $2, $3, $4
Also I am not sure that the redirect arg will work as you think it should. you may need to escape it?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| cevans |
| Posted: Tue Apr 29, 2014 7:48 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
Apart from required environment differences I have configured this to work on Windows now so I believe there is a defect with the product in Linux and am raising a PMR.
I ran a trace in Linux and there was no obvious errors the main parts of interest were ..
2561 14:44:48.622720 17628.1 : Adding process(MYDLQHANDLER) sequence(16)
14:44:48.622726 17628.1 : ---} zupAddProcessEntry rc=OK
14:44:48.622733 17628.1 : ---{ xcsExecProgram
14:44:48.622740 17628.1 : Name: /var/mqm/qmgrs/IB9QMGR/dlqhandler.sh
14:44:48.622744 17628.1 : Arg 0: /var/mqm/qmgrs/IB9QMGR/dlqhandler.sh
14:44:48.622747 17628.1 : Arg 1: IB9QMGR.DLQ
14:44:48.622751 17628.1 : Arg 2: IB9QMGR
14:44:48.622754 17628.1 : Arg 3: <
14:44:48.622758 17628.1 : Arg 4: /var/mqm/qmgrs/IB9QMGR/dlqhandler.rules
14:44:48.622776 17628.1 : statBuf.st_mode = 0x81ed
14:44:48.624270 17628.1 : Data: 0x00005b8a
3242 14:44:48.641847 17628.1 : Started process /var/mqm/qmgrs/IB9QMGR/dlqhandler.sh with pid 23434
3605 14:44:48.779339 17628.1 : Process(23434) has exited. |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Apr 29, 2014 8:11 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Did you also trace the runmqdlq process? If so, was there any mention of the AMQ8758 error in the runmqdlq trace? Or any indication of an error when runmqdlq was opening and reading the input file? |
|
| Back to top |
|
|
| cevans |
| Posted: Tue Apr 29, 2014 8:33 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
| tczielke wrote: |
| Did you also trace the runmqdlq process? If so, was there any mention of the AMQ8758 error in the runmqdlq trace? Or any indication of an error when runmqdlq was opening and reading the input file? |
I used the following for the trace
strmqtrc -m qmgr -t all -p amqzmgr0,runmqdlq
There was no AMQ errors at all or any indication of an error when runmqdlq was opening ... although I am not sure what I am looking for exactly, there was nothing that looked like an error or anything unusual compared to the rest of the trace. Any suggestions welcomed |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Apr 29, 2014 8:45 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I see the following in a runmqdlq trace:
11:36:11.264284 6761.1 : -> odqProcessStdin
.
.
.
11:36:11.267277 6761.1 CONN:1400006 } odqProcessStdin rc=OK
That looks like the part where runmqdlq is reading the standard input, to me. Do you see any errors around this function in the runmqdlq trace?
Also, what do you see when you do the following on your amqzmgr0 process (i.e. pid was 12345).
ps -p 12345 -o uid,ruid,suid,fuid
Are they all those ids the same, or do any ids have a different value? |
|
| Back to top |
|
|
| cevans |
| Posted: Tue Apr 29, 2014 8:50 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
| tczielke wrote: |
I see the following in a runmqdlq trace:
11:36:11.264284 6761.1 : -> odqProcessStdin
.
.
.
11:36:11.267277 6761.1 CONN:1400006 } odqProcessStdin rc=OK
That looks like the part where runmqdlq is reading the standard input, to me. Do you see any errors around this function in the runmqdlq trace?
Also, what do you see when you do the following on your amqzmgr0 process (i.e. pid was 12345).
ps -p 12345 -o uid,ruid,suid,fuid
Are they all those ids the same, or do any ids have a different value? |
I have no matches if I search for odqProcessStdin in the trace file
Do you think I need to run the trace again for only runmqdlq? ie
strmqtrc -m qmgr -t all -p runmqdlq
The process does not run long enough for me to be able to use ps -p to get any details |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Apr 29, 2014 8:56 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
The ps command to run was for your amqzmgr0 process on your queue manager. That is a long running process and should be out there. What I am trying to see there is if someone started the queue manager under their own id, and not mqm. If so, the ruid (real user id) stays as the original user, and I believe Linux will do file security checks against the real user id. So it is possible that runmqdlq (which would inherit its ids from its parent process amqzmgr0) does not have access to open the input file, if you assumed it would be running under mqm.
When you run this trace command:
strmqtrc -m qmgr -t all -p amqzmgr0,runmqdlq
and then cause your runmqdlq service to be initiated, you should see at least 2 traces being created. One for amqzmgr0 and one for runmqdlq. When you look at the top of the trace, you can check the Program Name to see which trace the program was run on. There should be one for runmqdlq. |
|
| Back to top |
|
|
| cevans |
| Posted: Tue Apr 29, 2014 9:01 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
| tczielke wrote: |
The ps command to run was for your amqzmgr0 process on your queue manager. That is a long running process and should be out there. What I am trying to see there is if someone started the queue manager under their own id, and not mqm. If so, the ruid (real user id) stays as the original user, and I believe Linux will do file security checks against the real user id. So it is possible that runmqdlq (which would inherit its ids from its parent process amqzmgr0) does not have access to open the input file, if you assumed it would be running under mqm.
When you run this trace command:
strmqtrc -m qmgr -t all -p amqzmgr0,runmqdlq
and then cause your runmqdlq service to be initiated, you should see at least 2 traces being created. One for amqzmgr0 and one for runmqdlq. When you look at the top of the trace, you can check the Program Name to see which trace the program was run on. There should be one for runmqdlq. |
Here is the entire trace for runmqdlq
WebSphere MQ Formatted Trace - Formatter V3
+-----------------------------------------------------------------------+
| |
| WebSphere MQ Formatted Trace V3 |
| =============================== |
| |
| Date/Time :- 04/28/2014 14:44:38 GMT |
| UTC Time :- 1398692678.773751 |
| UTC Time Offset :- -1 (GMT) |
| Host Name :- localhost.localdomain |
| Operating System :- Linux 2.6.32-431.el6.x86_64 |
| LVLS :- 7.5.0.1 |
| Product Long Name :- WebSphere MQ for Linux (x86-64 platform) |
| Build Level :- p750-001-130308 |
| Installation Path :- /opt/mqm |
| Installation Name :- Installation1 (1) |
| Effective UserID :- 496 (mqm) |
| Real UserID :- 500 (cevans) |
| Program Name :- runmqdlq |
| Addressing Mode :- 64-bit |
| Process :- 21716 |
| QueueManager :- IB9QMGR |
| Reentrant :- 1 |
| |
+-----------------------------------------------------------------------+
Formatting options: None
Formatter installation path: /opt/mqm
Formatter version: 7.5.0.1
Timestamp Process.Thread Trace Ident Trace Data
===========================================================
*14:44:38.774606 21716.1 CONN:1400006 Data: 0x10806020
14:44:38.774623 21716.1 CONN:1400006 Data: 0x00000442 0x00000000
14:44:38.774644 21716.1 CONN:1400006 Thread stack (from libmqmcs_r.so)
14:44:38.826547 21716.1 CONN:1400006 -> odqProcessQueue
14:44:38.826603 21716.1 CONN:1400006 -> odqGetNext
14:44:38.826742 21716.1 CONN:1400006 -> MQGET
14:44:38.826817 21716.1 CONN:1400006 -> zstMQGET
14:44:38.826884 21716.1 CONN:1400006 -> ziiMQGET
14:44:38.826897 21716.1 CONN:1400006 -> ziiSendReceiveAgent
14:44:38.826961 21716.1 CONN:1400006 -> zcpReceiveOnPipe
14:44:38.826986 21716.1 CONN:1400006 -> xcsWaitEventSem
14:44:38.827007 21716.1 CONN:1400006 -> xlsWaitEvent
14:44:38.827018 21716.1 CONN:1400006 -> xlsUnlockEvent
14:44:38.827033 21716.1 CONN:1400006 ---------{ xlsUnlockEvent
14:44:38.827045 21716.1 CONN:1400006 ---------} xlsUnlockEvent rc=OK
14:44:38.827050 21716.1 CONN:1400006 --------}! xlsWaitEvent rc=xecL_W_TIMEOUT
14:44:38.827054 21716.1 CONN:1400006 -------}! xcsWaitEventSem rc=xecL_W_TIMEOUT
14:44:38.827081 21716.1 CONN:1400006 ------}! zcpReceiveOnPipe rc=zrcC_E_TIMEOUT
14:44:38.827093 21716.1 CONN:1400006 ------{ ziiHealthCheck
14:44:38.827285 21716.1 CONN:1400006 AgentPid:17640, hAgentPid:{Flags:1, Pid:17640, Handle:17640}, hAgentThread:{Flags:1, Pid:17640, Handle:17640}
14:44:38.827305 21716.1 CONN:1400006 -------{ xcsCheckProcess
14:44:38.827315 21716.1 CONN:1400006 pid(17640)
14:44:38.827326 21716.1 CONN:1400006 Data: 0x000044e8
14:44:38.827337 21716.1 CONN:1400006 -------} xcsCheckProcess rc=OK
14:44:38.827341 21716.1 CONN:1400006 ------} ziiHealthCheck rc=OK
14:44:38.827346 21716.1 CONN:1400006 ------{ zcpReceiveOnPipe
14:44:38.827351 21716.1 CONN:1400006 -------{ xcsWaitEventSem
14:44:38.827368 21716.1 CONN:1400006 xcsWaitEventSem shmid:1::0::0-599528
14:44:38.827378 21716.1 CONN:1400006 --------{ xlsWaitEvent
14:44:38.827438 21716.1 CONN:1400006 EventId:177 Timeout:10000 Flags:0x442
14:44:38.827450 21716.1 CONN:1400006 ---------{ xlsUnlockEvent
14:44:38.827455 21716.1 CONN:1400006 ---------} xlsUnlockEvent rc=OK
14:44:38.827462 21716.1 CONN:1400006 Data: 0x00000004 0x00000000
*14:44:48.828045 21716.1 CONN:1400006 Data: 0x0000006e
14:44:48.828085 21716.1 CONN:1400006 Data: 0x10806020
14:44:48.828091 21716.1 CONN:1400006 Data: 0x00000443 0x00000000
14:44:48.828095 21716.1 CONN:1400006 ---------{ xlsUnlockEvent
14:44:48.828099 21716.1 CONN:1400006 ---------} xlsUnlockEvent rc=OK
14:44:48.828101 21716.1 CONN:1400006 --------}! xlsWaitEvent rc=xecL_W_TIMEOUT
14:44:48.828103 21716.1 CONN:1400006 -------}! xcsWaitEventSem rc=xecL_W_TIMEOUT
14:44:48.828106 21716.1 CONN:1400006 ------}! zcpReceiveOnPipe rc=zrcC_E_TIMEOUT
14:44:48.828110 21716.1 CONN:1400006 ------{ ziiHealthCheck
14:44:48.828116 21716.1 CONN:1400006 AgentPid:17640, hAgentPid:{Flags:1, Pid:17640, Handle:17640}, hAgentThread:{Flags:1, Pid:17640, Handle:17640}
14:44:48.828120 21716.1 CONN:1400006 -------{ xcsCheckProcess
14:44:48.828123 21716.1 CONN:1400006 pid(17640)
14:44:48.828128 21716.1 CONN:1400006 Data: 0x000044e8
14:44:48.828134 21716.1 CONN:1400006 -------} xcsCheckProcess rc=OK
14:44:48.828137 21716.1 CONN:1400006 ------} ziiHealthCheck rc=OK
14:44:48.828140 21716.1 CONN:1400006 ------{ zcpReceiveOnPipe
14:44:48.828143 21716.1 CONN:1400006 -------{ xcsWaitEventSem
14:44:48.828146 21716.1 CONN:1400006 xcsWaitEventSem shmid:1::0::0-599528
14:44:48.828150 21716.1 CONN:1400006 --------{ xlsWaitEvent
14:44:48.828154 21716.1 CONN:1400006 EventId:177 Timeout:10000 Flags:0x443
14:44:48.828157 21716.1 CONN:1400006 ---------{ xlsUnlockEvent
14:44:48.828160 21716.1 CONN:1400006 ---------} xlsUnlockEvent rc=OK
14:44:48.828163 21716.1 CONN:1400006 Data: 0x00000004 0x00000000
*14:44:58.828477 21716.1 CONN:1400006 Data: 0x0000006e
14:44:58.828533 21716.1 CONN:1400006 Data: 0x10806020
14:44:58.828544 21716.1 CONN:1400006 Data: 0x00000444 0x00000000
14:44:58.828551 21716.1 CONN:1400006 ---------{ xlsUnlockEvent
14:44:58.828556 21716.1 CONN:1400006 ---------} xlsUnlockEvent rc=OK
14:44:58.828560 21716.1 CONN:1400006 --------}! xlsWaitEvent rc=xecL_W_TIMEOUT
14:44:58.828565 21716.1 CONN:1400006 -------}! xcsWaitEventSem rc=xecL_W_TIMEOUT
14:44:58.828570 21716.1 CONN:1400006 ------}! zcpReceiveOnPipe rc=zrcC_E_TIMEOUT
14:44:58.828576 21716.1 CONN:1400006 ------{ ziiHealthCheck
14:44:58.828585 21716.1 CONN:1400006 AgentPid:17640, hAgentPid:{Flags:1, Pid:17640, Handle:17640}, hAgentThread:{Flags:1, Pid:17640, Handle:17640}
14:44:58.828592 21716.1 CONN:1400006 -------{ xcsCheckProcess
14:44:58.828598 21716.1 CONN:1400006 pid(17640)
14:44:58.828605 21716.1 CONN:1400006 Data: 0x000044e8
14:44:58.828616 21716.1 CONN:1400006 -------} xcsCheckProcess rc=OK
14:44:58.828621 21716.1 CONN:1400006 ------} ziiHealthCheck rc=OK
14:44:58.828625 21716.1 CONN:1400006 ------{ zcpReceiveOnPipe
14:44:58.828631 21716.1 CONN:1400006 -------{ xcsWaitEventSem
14:44:58.828637 21716.1 CONN:1400006 xcsWaitEventSem shmid:1::0::0-599528
14:44:58.828643 21716.1 CONN:1400006 --------{ xlsWaitEvent
14:44:58.828650 21716.1 CONN:1400006 EventId:177 Timeout:10000 Flags:0x444
14:44:58.828679 21716.1 CONN:1400006 ---------{ xlsUnlockEvent
14:44:58.828685 21716.1 CONN:1400006 ---------} xlsUnlockEvent rc=OK
14:44:58.828692 21716.1 CONN:1400006 Data: 0x00000004 0x00000000
*14:45:08.829208 21716.1 CONN:1400006 Data: 0x0000006e
=========================================================== |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Apr 29, 2014 9:09 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
So I see this in your trace:
| Effective UserID :- 496 (mqm) |
| Real UserID :- 500 (cevans) |
If that trace was from when the runmqdlq service was run, that is what I was suspecting as a potential issue.
So basically, your queue manager is running with an effective user id of 496 (mqm) and a real user id of 500 (cevans). What probably happened here is you started your queue manager with the cevans (500) id.
Does your id (500) have access to read the input file that you are passing into the runmqdlq process?
Also, this is bad practice. You want to start your queue manager with the mqm id. |
|
| Back to top |
|
|
| cevans |
| Posted: Wed Apr 30, 2014 5:29 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
| tczielke wrote: |
So I see this in your trace:
| Effective UserID :- 496 (mqm) |
| Real UserID :- 500 (cevans) |
If that trace was from when the runmqdlq service was run, that is what I was suspecting as a potential issue.
So basically, your queue manager is running with an effective user id of 496 (mqm) and a real user id of 500 (cevans). What probably happened here is you started your queue manager with the cevans (500) id.
Does your id (500) have access to read the input file that you are passing into the runmqdlq process?
Also, this is bad practice. You want to start your queue manager with the mqm id. |
The queue manager is now running as mqm ...
WebSphere MQ Formatted Trace - Formatter V3
+-----------------------------------------------------------------------+
| |
| WebSphere MQ Formatted Trace V3 |
| =============================== |
| |
| Date/Time :- 04/30/2014 11:35:07 GMT |
| UTC Time :- 1398854107.594140 |
| UTC Time Offset :- -1 (GMT) |
| Host Name :- localhost.localdomain |
| Operating System :- Linux 2.6.32-431.el6.x86_64 |
| LVLS :- 7.5.0.1 |
| Product Long Name :- WebSphere MQ for Linux (x86-64 platform) |
| Build Level :- p750-001-130308 |
| Installation Path :- /opt/mqm |
| Installation Name :- Installation1 (1) |
| Effective UserID :- 496 (mqm) |
| Real UserID :- 496 (mqm) |
| Program Name :- amqzmgr0 |
| Addressing Mode :- 64-bit |
| Process :- 1866 |
| QueueManager :- |
| Reentrant :- 1 |
| |
+-----------------------------------------------------------------------+
Formatting options: None
Formatter installation path: /opt/mqm
Formatter version: 7.5.0.1
Timestamp Process.Thread Trace Ident Trace Data
===========================================================
*11:35:14.669439 1866.1 : Thread stack (from libmqmcs_r.so)
however I am unable to generate any output for the trace of runmqdlq. Only the output for amqzmgr0 is generated?? |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Apr 30, 2014 5:34 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Does your runmqdlq service now work with the queue manager being started under mqm? Or does it exhibit the same behavior as before? |
|
| Back to top |
|
|
| cevans |
| Posted: Wed Apr 30, 2014 5:35 am Post subject: |
|
|
Apprentice
Joined: 18 Jul 2013
Posts: 26
|
| tczielke wrote: |
| Does your runmqdlq service now work with the queue manager being started under mqm? Or does it exhibit the same behavior as before? |
Exactly the same behaviour .. starts and then promptly ends
nothing more in the logs |
|
| Back to top |
|
|
|
|
