Pkg_app and its uses

Many Customers and Engineers may wonder at what pkg_app is and how it is used.

Pkg_app is a shell script originally created by Rick Zagorski of Sun Microsystems in 2003.  Rick moved on to other projects and left Pkg_app without an author so I stepped in and thanks to Rick was allowed to continue its development.

Q: What is Pkg_app?

A: Pkg_app is a script that can take a a core/gcore or process id and gather all the libraries required by Sun Support to debug a core/gcore file.  

Q: Why are the libraries needed in this way?

A: There are a multitude of Solaris OE versions and even more Patch versions; not all Customers can keep their servers 100% up to date.  Sun Support needs to have a server setup exactly like the Customers environment in which to debug core files; core files and their respective processes pre-load the libraries from the system.  

The quickest way to get this custom environment up and online is to just gather the libraries listed in the core or process.  The time it takes a Customer to run Pkg_app and uploaded the resulting file is a thousand times faster than getting a full Solaris Explorer, locating an available server, re-OS'ing the server to the Explorer specification and debugging the core.

Q: Why use Pkg_app?

A:  Pkg_app makes it easier to grab the library and process binary files than manually locating all files and copying them into one specific path.  The number of library files gathered depends on the libraries used by the process that created the core.  In a Directory Server's case, it can use approx. 68 in 5.2 servers and upwards of 82 libraries in 6.2.  Gathering these files manually could be a time consuming task for a Customer when time is of the essence.

Q: How do you use Pkg_app?

A:  Executing Pkg_app is easy and if not used with any parameters will display its usage.

As seen from the Usage, there are really only two parameters required to run Pkg_app.

 1) the full path including the name to the core file or the process id (pid).
 2) the path (path only) to the process binary that create the core or of the pid.


\* Sun Microsystems RSD pkg_app 2.7 Solaris                      [05/09/2008]


pkg_app 2.7, a Sun Microsystems data gathering utility.


  ./pkg_app [options] -c <core file | pid> -p <full path to process binary> -s [path to write tar file]

Required parameters:

 -c <core file OR pid of a running process>

 -p <full path to process binary> (ns-slapd, imapd, httpd etc.)

Optional parameters:

 -i (Include the core file with the final tar.gz)

 -q (Quiet)

 -d (Debug)

 -s <Storage; path to store the final tar file in>

usage:  ./pkg_app -c <name of the core file> -p <path to process binary>

usage:  ./pkg_app -c <pid of the running app> -p <path to process binary>

Examples: these are examples mixing various parameters

Directory Server

./pkg_app -i -c ./core.14740 -p /var/mps/ds52p4/bin/slapd/server/64

Messaging Server

./pkg_app -c ./core.3496 -p /opt/SUNWmsgsr/lib

Web Server

./pkg_app ./core.1092 -p /space/iws70/lib -s /var/crash

Calendar Server

./pkg_app -i -c ./core -p /opt/SUNWics5/cal/lib

Q: How do I know the process binary name?

A: You can use the "file" command to find the process binary name

#file core.2894

core.2894:      ELF 64-bit MSB core file SPARCV9 Version 1, from 'ns-slapd'

Q: How do I find the path to the process binary?

You can use pldd or "find" in the process binaries install path.

1) Using pldd.  You can see the full path to ns-slapd is /opt/dsee62/ds6/lib/64

#pldd core.2894 | head -1

core 'core.2894' of 2894:       /opt/dsee62/ds6/lib/64/ns-slapd -D /opt/dsee62/var/dscc6/dcc/ads -i /o

2) Using find.  I know the server install path is /opt/dsee62 and the path to ns-slapd is /opt/dsee62/ds6/lib/sparcv9/  

#cd /opt/dsee62

root[/opt/dsee62]#find . -name ns-slapd -print


root[/opt/dsee62]#cd ./ds6/lib/sparcv9



Please note: the path seen in the pldd and that of the "find" are the same.  Directory Server uses a Link between 64 pointing to sparc9 here.

#diff /opt/dsee62/ds6/lib/64/ns-slapd /opt/dsee62/ds6/lib/sparcv9/ns-slapd

Example Testrun:

1) Locate a core file, in this case a gcore from a 6.2 Directory Server
2) Locate the process binary as per above.

#./pkg_app -c ./core.2894 -p /opt/dsee62/ds6/lib/sparcv9


\* Sun Microsystems RSD pkg_app 2.7 Solaris                      [05/09/2008]


\* OS release                            [5.10]

\* Platform                              [SUNW,Sun-Blade-2500]

\* Using core                            [/var/tmp/cores/core.2894]

\* Process Root                          [/opt/dsee62/var/dscc6/dcc/ads]

\* Process binary                        [ns-slapd]

\* ns-slapd binary bit version           [64]

\* Checking path to binary name          [success, path != binary name]

\* Checking path is a directory          [success]

\* Locating ns-slapd                     [success]

\* Checking located ns-slapd is 64 bit   [success]

\* Binary located                        [/opt/dsee62/ds6/lib/sparcv9/ns-slapd]

\* Adding binary to pkg_app.pldd         [success]

\* Grabbing pldd                         [success]

\* Grabbing pstack                       [success]

\* Grabbing pmap                         [success]

\* Grabbing pcred                        [success]

\* Grabbing pflags                       [success]


\* Databin Used                          [/var/tmp/cores]

\* Using hostid for naming .tar.gz       [837872d0]

\* Writing file                          [pkg_app837872d0-s4u-2500a-brm04-080509-092119.tar.Z]


\* Processing file 82 of 82


\* Done gathering files

\* Writing dbx files                     [success]

\* Creating final tarfile                [success]

\* Compressing tarfile                   [success]


Operations Complete

Upload this file to your Cores Directory at Sun

File located in directory .

                [ pkg_app837872d0-s4u-2500a-brm04-080509-092119.tar.Z ]

                                Thank you.

                                Sun Software Technology Service Center (STSC)


1) You can check for updates to this script here:

        BigAdmin -

2) Release Notes and Guides located here:

        Docs -

3) GDD information located here:

        Docs -

4) Please send all Bugs and RFE's to the following address:

        Subject "pkg_app bug/rfe" -

5) Please send all other questions etc to:

        Subject "pkg_app feedback" -

Other things to note are the Optional parameters.

Optional parameters:
 -i (Include the core file with the final tar.gz)
 -q (Quiet)
 -d (Debug)
 -s <Storage; path to store the final tar file in>

1)  -i (Include the core file with the final tar.gz)

If Sun Support does not yet have the core file, the Customer can include the core/gcore with the final Pkg_app tar.gz file

2)  -q (Quiet)

This will run Pkg_app in a completely silent mode.  No STDOUT to the terminal.  Good for use within other applications or via a cron.

3)  -d (Debug)

The Debug feature is like Verbose.  It spits out more info on what Pkg_app is doing and the internal parameters as they are built.  This can help me debug pkg_app issues.

4)  -s <Storage; path to store the final tar file in>

The Storage switch allows the Customer to give Pkg_app a new path to store the resulting pkg_app tar.gz file otherwise Pkg_app creates/stores the file in the current path.

This is all for today but I hope to show how Dirtracer uses Pkg_app.


< -d (Debug)>

Posted by guest on April 16, 2010 at 03:54 PM MDT #

Post a Comment:
  • HTML Syntax: NOT allowed

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.


« June 2016