Thursday Apr 14, 2011

Pkgapp 3.5 Released!

Pkgapp 3.5 Released!

Photo © Lee Trujillo

I've fixed a few bugs, added some great enhancements and changed some of the output during run-time.  Please note, all downloads for Pkgapp (and DirTracer) will only be available via the My Oracle Support portal.  I hope to have all references to Pkgapp and DirTracer taken off the old BigAdmin and replaced with a reference to the support portal. 

[Read More]

Thursday Mar 10, 2011

DT7.0 and Pkgapp 3.4 Available via the My Oracle Support portal

Due to popular demand...

Photo © Lee TrujilloI've added the DirTracer and Pkgapp tar files to a Knowledge Portal document so customers now can access and download from a more reliable location.  

Please login to the My Oracle Support portal and search for the following Doc ID.

  • DirTracer7 (DT7) - Oracle Support Doc ID 1291443.1
  • Pkgapp 3.4 - Oracle Support Doc ID 1274584.1

This document is a truncated copy of the included .pdf file included with the Pkgapp bundle.  See the "Download" links near the bottom.

Cheers!

Lee

Tuesday Jun 02, 2009

Pkgapp 3.2 for Solaris available on BigAdmin

 

Hey all,

Quick update to say Pkgapp 3.2 is now available externally on the Big Admin scripts site.  You can download it here.

Currently I am working on Pkgapp 3.2 ports to Linux.

Big Admin Scripts: Sun Java System Category

Big Admin MOTD

Cheers!

Lee

Thursday May 21, 2009

Pkgapp 3.2 for Solaris released!

Hi all!

Pkgapp 3.2 is available internally...yeah!

Artistic Bridge

I finally had time to update the Pkgapp documentation and retest it on various application cores/gcores and it is now ready for prime time.  I have also submitted it to BigAdmin and it should be available in the next few days.  If you need it now, please contact your favorite Sun Support representative and request he send it from the internal download site.  I will also update "this" post once Big Admin has uploaded the new version.

Pkgapp 3.2 has 2 big new features...

  1. It includes adm64 libraries that were previously not included making debugging easier on that platform for java issues.
  2. It includes a new core truncation feature developed by a member of the Directory Server Sustaining team.  The great news is, the feature not only works on Directory Server cores but any other core/gcore you may be dealing with!

If the core/gcore is good, the user is given the following message:

\* Checking if corefile is truncated     [CORE gcore.cshttpd.28734 GOOD Core contains 293 segments ]

If the core is truncated, the user is alerted and required to answer yes/no as to whether they understand the data may be totally unusable.

\* Checking if corefile is truncated     [WARNING! core gcore.cshttpd.28734.truncated is truncated (40396864d bytes instead of 40397397d bytes)]
\*                                     
\* ALERT! The core was found to be truncated, it therefore may not be usable
\* pkgapp will continue to gather data and you can still upload the result to Sun
\*                                     
\* Do you understand the core may not be usable? [yes|no] yes
                                        [Answer was -> yes]
\* Continuing...  

If you use/have an RSS Reader such as NetNewsWire or  Google Reader you can see the latest updates to Big Admin using the following links.

Big Admin Scripts: Sun Java System Category

Big Admin MOTD

Next up...I plan to finalize and release DTR and begin production of my first SLX video for Dirtracer users!

Take care,

Lee

Tuesday May 13, 2008

Pkg_app and Dirtracer

Today I will revisit Pkg_app but will focus on its uses within Dirtracer.

Before Dirtracer 6.0.4 Customers who would use Dirtracer to gather cores and gcores would have to run Pkg_app manually after the fact.

Since version 6.0.4 Dirtracer has included Pkg_app in the <Dirtracer Install Path>/dirtracertools/ location and with the Quiet (-q) switch in Pkg_app 2.7 I able to embed Pkg_app within Dirtracer to run automatically.

If a Customer uses the following config file parameters Pkg_app will be launched automatically.

CORE_LOCATION="<full path to the core> + SERVER_DOWN="1"

GRAB_GCORE="1" or GRAB_GCORE="2"

Here is an example of the following config:  I used 1 check and 1 second interval for brevity.

NUMBEROFCHECKS="1"
INTERVAL="1"
GRAB_GCORE="1"

See the runtime-<date>-<time>.log:

As you see below Dirtracer completes a quick one second loop, exits the Main Loop and grabs a Gcore.

<SNIP>
\*   pms.sh interval(1) x checks(1)      [pms.sh run time (1 sec.)]
\*                                       
\* Entering Main Performance Gathering Loop
\*                                       
\* Loop 0 - 080509-075120                
\*                                       
\* Grabbing gcore 080509-075122          [success]
</SNIP>

Once Dirtracer finishes with the Post Loop gathering, it executed Pkg_app to have it gather all libraries and the ns-slapd binary.  Note the normal Pkg_app processing information is not seen because Pkg_app has been launched with the Quiet (-q) option.

<SNIP>
\* Packaging files                       
\*   Preparing files - pkg_app           [waiting 120 sec.]      [success]
</SNIP>

In Dirtracer 6.0.4 customers grabbing large cores/gcores with Dirtracer saw what they thought was a pkg_app hang.  It was likely the core/gcore had overflowed the core header and Pkg_app could not process the file correctly.  As a result I created a timer function to monitor processes like Pkg_app.  

If the Pkg_app runs for more than 120 seconds, then Dirtracer will "kill" the pkg_app process and alert the Customer they need to run Pkg_app manually.

<SNIP>
\* Packaging files                       
\*   Preparing files - pkg_app           [killed]
</SNIP>

If Pkg_app was successful then it will present the Customer with the following message; see 2) below.

<SNIP>
1) Dirtracer capture data located in directory [ /var/tmp/data/051308-01 ]

Upload "only" this file to your supportfiles.sun.com cores directory at Sun

        [ dirtracer-834d2699-kaneda-080513-090202.tar.gz ]

2) pkg_app has captured system libs as the result of a gcore or core being found
                As this file may be large, please ftp this separately to Sun
                pkg_app file located in /var/tmp/data/051308-01/pkg_app_data

                [pkg_app834d2699-kaneda-080513-090347.tar.Z ]
</SNIP>

Currently Dirtracer does not give a major alert if Pkg_app was killed.  The customer should manually run Pkg_app or gather the libraries used by the process.

[LT]
About

A Tech Blog about the Sun Java Systems Dirtracer Toolkit. Dirtracer and this blog written and maintained by Lee Trujillo an Oracle Senior Principal Support Engineer.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today