Sponsored Content
Operating Systems Solaris what time did my process die ?? Post 302093511 by Hitori on Friday 20th of October 2006 02:06:51 AM
Old 10-20-2006
Another way is to run process from a programm (that will be a parent) and wait when the process is finished (use fork/exec/waitpid functions).

I do not know whether waitpid() can be used by process that is not a parent for process with given pid.
 

8 More Discussions You Might Find Interesting

1. News, Links, Events and Announcements

Live Free or Die!

Mods: Delete this if you think that this is not appropriate. I found this rather amusing. If you go to www.unix.net now you will see the OpenGroup selling license plates that read "Live Free or Die/Unix/Unix is a trademark of the OpenGroup" (http://www.unix.net/unix_plates.html) I just... (12 Replies)
Discussion started by: auswipe
12 Replies

2. UNIX for Dummies Questions & Answers

Python 2.5 must die.

I am using SunOS 5.7 I have installed Python 2.5 via make install Without going into details, I'd like to uninstall it and replace it with an earlier version. Maybe as far back as 2.2.3. Unfortuantely, make uninstall gives me Don't know how to make target 'uninstall'. This is thematically... (2 Replies)
Discussion started by: Dbecker
2 Replies

3. UNIX for Dummies Questions & Answers

how to Decrease priority of a particular process in time of process creation

how to decrease priority of a particular process in time of process creation... and also how to decrease priority of a particular process after process creation.. can any one please help me out... (2 Replies)
Discussion started by: Ramkum
2 Replies

4. UNIX for Advanced & Expert Users

Process accounting and Shell process time

Hi All, I am running the following accounting on one of my executable, $ accton /home/myexe-acct $ ./myexe $ accton When I check the process timings I get the below result, Shell process time: 300ms myexe time: 100ms I want to know on why the shell(sh) process is taking so much time... (1 Reply)
Discussion started by: santoshbr4
1 Replies

5. Linux

Process start time not showing correct time

Process start time is not showing the correct time: I had started a process on Jun 17th at 23:30:00. Next day morning when I run the command "ps -ef | grep mq", the process is showing the start date of Jun 17th but the start time is 00:16:41 Day/Date is setup correctly on the server. It... (2 Replies)
Discussion started by: hemangjani
2 Replies

6. Shell Programming and Scripting

How to calculate time difference between start and end time of a process!

Hello All, I have a problem calculating the time difference between start and end timings...! the timings are given by 24hr format.. Start Date : 08/05/10 12:55 End Date : 08/09/10 06:50 above values are in mm/dd/yy hh:mm format. Now the thing is, 7th(08/07/10) and... (16 Replies)
Discussion started by: smarty86
16 Replies

7. Shell Programming and Scripting

FTP Connection die out

Hi, I will ftp aroung 80 files after connecting to an FTP Server. But after 2 minutes of connection, it is timed out and connection is dying. Server had a 2 minute connection timeout if connection is idle. But my question, Isn't tranfering files not considered as an activity. Is the connection... (7 Replies)
Discussion started by: vasuarjula
7 Replies

8. AIX

oracle process appears to die

periodically my oracle 11.2.0.1 listener process 'tnslsnr' seems to crash and disappear ( I am using an AIX 6.1 unix platform ). When this happens I am able to restart my listener ok. However when this happens there is is no stop recorded in my listener log (as there normally would be - hence why I... (1 Reply)
Discussion started by: jimthompson
1 Replies
Test::Fatal(3)						User Contributed Perl Documentation					    Test::Fatal(3)

NAME
Test::Fatal - incredibly simple helpers for testing code with exceptions VERSION
version 0.010 SYNOPSIS
use Test::More; use Test::Fatal; use System::Under::Test qw(might_die); is( exception { might_die; }, undef, "the code lived", ); like( exception { might_die; }, qr/turns out it died/, "the code died as expected", ); isa_ok( exception { might_die; }, 'Exception::Whatever', 'the thrown exception', ); DESCRIPTION
Test::Fatal is an alternative to the popular Test::Exception. It does much less, but should allow greater flexibility in testing exception-throwing code with about the same amount of typing. It exports one routine by default: "exception". FUNCTIONS
exception my $exception = exception { ... }; "exception" takes a bare block of code and returns the exception thrown by that block. If no exception was thrown, it returns undef. Achtung! If the block results in a false exception, such as 0 or the empty string, Test::Fatal itself will die. Since either of these cases indicates a serious problem with the system under testing, this behavior is considered a feature. If you must test for these conditions, you should use Try::Tiny's try/catch mechanism. (Try::Tiny is the underlying exception handling system of Test::Fatal.) Note that there is no TAP assert being performed. In other words, no "ok" or "not ok" line is emitted. It's up to you to use the rest of "exception" in an existing test like "ok", "isa_ok", "is", et cetera. Or you may wish to use the "dies_ok" and "lives_ok" wrappers, which do provide TAP output. "exception" does not alter the stack presented to the called block, meaning that if the exception returned has a stack trace, it will include some frames between the code calling "exception" and the thing throwing the exception. This is considered a feature because it avoids the occasionally twitchy "Sub::Uplevel" mechanism. Achtung! This is not a great idea: like( exception { ... }, qr/foo/, "foo appears in the exception" ); If the code in the "..." is going to throw a stack trace with the arguments to each subroutine in its call stack, the test name, "foo appears in the exception" will itself be matched by the regex. Instead, write this: my $exception = exception { ... }; like( $exception, qr/foo/, "foo appears in the exception" ); Achtung: One final bad idea: isnt( exception { ... }, undef, "my code died!"); It's true that this tests that your code died, but you should really test that it died for the right reason. For example, if you make an unrelated mistake in the block, like using the wrong dereference, your test will pass even though the code to be tested isn't really run at all. If you're expecting an inspectable exception with an identifier or class, test that. If you're expecting a string exception, consider using "like". success try { should_live; } catch { fail("boo, we died"); } success { pass("hooray, we lived"); }; "success", exported only by request, is a Try::Tiny helper with semantics identical to "finally", but the body of the block will only be run if the "try" block ran without error. Although almost any needed exception tests can be performed with "exception", success blocks may sometimes help organize complex testing. dies_ok lives_ok Exported only by request, these two functions run a given block of code, and provide TAP output indicating if it did, or did not throw an exception. These provide an easy upgrade path for replacing existing unit tests based on "Test::Exception". RJBS does not suggest using this except as a convenience while porting tests to use Test::Fatal's "exception" routine. use Test::More tests => 2; use Test::Fatal qw(dies_ok lives_ok); dies_ok { die "I failed" } 'code that fails'; lives_ok { return "I'm still alive" } 'code that does not fail'; AUTHOR
Ricardo Signes <rjbs@cpan.org> COPYRIGHT AND LICENSE
This software is copyright (c) 2010 by Ricardo Signes. This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself. perl v5.16.3 2012-02-16 Test::Fatal(3)
All times are GMT -4. The time now is 09:16 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy