| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Trigger monitor unable to resolve `pwd` |
« View previous topic :: View next topic » |
| Author |
Message
|
| scott9 |
 Posted: Fri Oct 31, 2003 11:04 am Post subject: Trigger monitor unable to resolve `pwd` |
 |
|
Acolyte
Joined: 11 Jul 2002
Posts: 62
Location: Sacramento,CA
|
We have MQ 5.3 (no CSD's) on HPUX 11. Suddenly, the trigger monitors on 3 different systems failed with the same problem: Unable to write output to the logfile, which is defined in the ENVRDATA for the process object as a relative path (e.g. APPLICID('/tmp/code') ENVRDATA(>> code.out). We learned through investigation that the application is unable to determine the current working directory (cwd) from cmd `pwd`.
Our temp fix was to hard code the absolute path in the ENVRDATA definition (e.g. APPLICID('/tmp/code') ENVRDATA(>> /tmp/code.out). On 2 systems, we restarted the trigger monitor to clear the problem. We left one in a temp fix mode to continue with troubleshooting.
Things we know:
* Obviously, something was changed but 'nobody' knows what
* runmqtrm can resolve pwd, but child processes cannot
(runmqtrm continued to log to it's redirected output. Only the
application couldn't resolve cwd.)
* `pwd` works fine.
* Restarting the triggers clears the problem.
Sorry for the long question. There's a lot to say. Any ideas why child processes might fail in this fashion? |
|
| Back to top |
|
 |
| Leafar |
| Posted: Fri Oct 31, 2003 11:54 am Post subject: Re: Trigger monitor unable to resolve `pwd` |
|
|
Acolyte
Joined: 03 Apr 2003
Posts: 74
Location: Buenos Aires
|
| Quote: |
Our temp fix was to hard code the absolute path in the ENVRDATA definition (e.g. APPLICID('/tmp/code') ENVRDATA(>> /tmp/code.out). On 2 systems, we restarted the trigger monitor to clear the problem. We left one in a temp fix mode to continue with troubleshooting.
|
You can try changing ENVRDATA(>> /tmp/code.out) for ('>>/tmp/code.out') maybe the child process is looking for /TMP/CODE.OUT path |
|
| Back to top |
|
|
| scott9 |
| Posted: Fri Oct 31, 2003 12:48 pm Post subject: |
|
|
Acolyte
Joined: 11 Jul 2002
Posts: 62
Location: Sacramento,CA
|
Thanks, but our temp fix works for us. What I'm more interested in learning is how the runmqtrm child processes could lose the environmental parameters from the parent process. At least, that is what I suspect is happening.
Logging after the fact indicates that the command `pwd` to get the current working directory is failing. We were able to temporarily fix the problem by hard coding the absolute path to "code.out", so getting the current working directory became irrelevant.
When you start runmqtrm from within a specified directory, that directory becomes the 'working directory'; therefore, `pwd` should always return that same directory. This works on the parent, but suddenly failed on the child process on 3 out of 10 systems all configured the same.
Anybody know of any good trace programs (like truss) available for HP? |
|
| Back to top |
|
|
| Leafar |
| Posted: Fri Oct 31, 2003 12:57 pm Post subject: |
|
|
Acolyte
Joined: 03 Apr 2003
Posts: 74
Location: Buenos Aires
|
This is the helpcreen of the tusc command (HP-UX 11
Usage: tusc [-<options>] <command [args ...]> -OR- <pid [pid ...]>
-a: show exec arguments
-A: append to output file
-b bsize: dump 'bsize' max bytes (-r/-w)
-c: count syscalls instead of printing trace
-d [+][!][fd | all]: select only syscalls using fd
-e: show environment variables
-E: show syscall entries
-f: follow forks
-F: show kernel's ttrace feature level
-g: don't attach to members of my session
-h: show state of all processes when idle
-i: don't display interruptible syscalls
-I start[/stop]: single-step and show instructions
-k: keep alive (wait for *all* processes)
-l: print lwpids
-L [!]lwps: [un]select these lwps
-n: print process names
-o [file|fd]: send trace output to file or fd
-p: print pids
-Q: be quiet about some warnings
-r [!][fd | all]: dump read buffers
-R: show syscall restarts
-s [!]syscalls: [un]select these syscalls
-S [!]signals: [un]select these signals
-t: detach process if it becomes traced
-T timestamp: print time stamps
-u: print user thread IDs (pthreads)
-v: verbose (some system calls only)
-V: print version
-w [!][fd | all]: dump write buffers
-x: print raw (hex) arguments
-z: only show failing syscalls |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
