On Thu, Jul 7, 2011 at 12:50 PM, HACKER Nora <nora.hac...@stgkk.at> wrote:
> ** > > Hi Rob, > > Thanks for your reply and your suggestions. > > So to make things really simple you basically make the following call: > ***system "ps -ef |grep -v grep |grep dbw |grep -q $db";* twice the > first time you get the list as expected the second time you get a -1 from > the OS. Would it be possible to capture more then just the -1 there > should (at least usually) also be a error message in human readable > format... that might provide you with a bit more insight into what the > reason is that the OS doesn't like you asking twice. > > > Normally, the OS errors in text format are also printed on the command > line, so I guess there is nothing more to display …!? > > > Personally I would simply to test repeat the call 10 times or so so > that in both cases it is executed 10 times. If the first 10 all working > without an issue and the second round throws errors then it certainly is > not > an OS issue but it must be that something else (on the OS level?) has > changed in the mean time. ps is a very basic command and I cannot imagine > what it might be that would cause that to trow an error, the grep command > might but only of if that $db variable is very strange. You might want to > try and print it before and after you make the actual system call just to > make sure that it does not "magically" change which looking at your code it > should not but then again the system call should not fail... > > Tried it, and the result is as follows – 10 times ok for the first round, > 10 errors for the second round. I also checked the $db variable, following > your suggestion, and it is set identically both times: > > Default-Tuxedo: mvrst > > DB: MVRSTDB > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Return code: 0 > > Status: 0 > > DB MVRSTDB is running > > DB: MVRSTDB > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Return code: -1 > > Status: 16777215 > > DB MVRSTDB is not running > > But as you can see above I have no idea why this script might be > behaving as weird as it does. I do suspect that something OS related is > the cause of the weirdness but having never even logged in to an AIX > machine > I can only guess... > > Nevertheless thanks for your effort J > > Cheers, > > Nora > I guess that is clear then there is a definite change between the first and the second attempt at this system call. The first time no mater how often you all it you get the same result over and over again. The second time you always get a return code -1. So it is the OS that for what ever reason sees the second request as something quite different then the first... I assume you have compared both out puts from: my $test = `ps -ef |grep -v grep |grep dbw |grep $db`; # print grepped ps list for debugging and found no difference there? You can in both cases execute this on the command line without issues... Try making a different system call like 'echo "Hello world' or something that simple just to see if this does the same and fails on the second try (it should) if it does I would have to say that your OS does not like your program running the same system call more then once (for what ever reason) Now if this was Solaris I would suggest a simple process trace to see exactly what the OS was seeing in terms of requests and what it was doing to cause it to choke on the second one. I don't know if this is possible on AIX if it is this would be the best option to figure it out. Lacking a tool like that I fear that I am at a loss as to how to even try and figure this one out. The Solaris process trace or ptrace as the tool is called allows you to see every call made on the OS level (open file, read memory, access port etc...) it allows you providing that you use more or push the output to a file to see exactly what a process is doing and why it is waiting, or failing to execute a certain call. It has helped me several times to find things like locks on files (also system files) due to other processes creating exclusive locks (seemingly random error explained) or issues with libraries that where so far down the dependency chain that no one even knew they where ever being called. Regards, Rob
