Just go to ftp://ftp.emc.com/pub/emcgrab/Unix/ to select yours and download(solaris, linux, aix etc.). The latest version is emcgrab-4.4.4.
emcgrab is also known as Remediation HEAT report. EMC grab report generates file that EMC or storage team might use for diagnostics and monitoring of storage usage by the client and possible issues; it also dumps logs/config into this file. This procedure proved to be safe, but need to be done out of hours if that`s possible.
If you receive these kinds of alerts in Solaris, it means your server has Memory Dimm issue. Please check with hrdconf/madmin(HP-UX) or prtconf(SUN solaris) to see the error message.
For more information about ECC memory, you can refer to the following article: http://en.wikipedia.org/wiki/ECC_memory
If you're looking at squid access.log, you'll find the first column of it is the time, for example:
1310313302.640 829 220.127.116.11 TCP_MISS/200 104 CONNECT smtp.126.com:25 - DIRECT/18.104.22.168 -
1310313303.484 1845 22.214.171.124 TCP_MISS/200 104 CONNECT smtp.126.com:25 - DIRECT/126.96.36.199 -
This is not very human readable. Now we can use perl to convert squid access.log time to human-readable format, just one line command:
cat /var/log/squid/access.log |perl -nwe's/^(\d+)/localtime($1)/e; print'
After this, it'll look like this:
Sun Jul 10 09:55:03 2011.484 1845 188.8.131.52 TCP_MISS/200 104 CONNECT smtp.126.com:25 - DIRECT/184.108.40.206 -
Sun Jul 10 09:55:07 2011.146 355 220.127.116.11 TCP_MISS/200 1176 GET http://spam-chaos.com/pp/set-cookie.php - DIRECT/18.104.22.168 text/html
Hey, more human-readable, right?
When I tried to start up IBM http server on my Solaris, I met this error message:
ld.so.1: httpd: fatal: libaprutil-0.so.0: open failed: No such file or directory
This error was caused by library libaprutil-0.so.0 can not be found in the current library path environment variable. We should add /apps/IBMHTTPD/Installs/IHS61-01/lib to LD_LIBRARY_PATH to make libaprutil-0.so.0 be seen by ld.
Here goes the resolution:
#export LD_LIBRARY_PATH=/apps/IBMHTTPD/Installs/IHS61-01/lib:$LD_LIBRARY_PATH #set environment variable
#/apps/IBMHTTPD/Installs/IHS61-01/bin/httpd -d /apps/IBMHTTPD/Installs/IHS61-01 -d /apps/IBMHTTPD/Installs/IHS61-01 -f /apps/IBMHTTPD/Installs/IHS61-01/conf/ihs.conf -k restart #restart IHS
#/usr/ucb/ps auxww|grep -i ibmhttpd #check the result
Here's more about ld.so: (from book <Optimizing Linux Performance: A Hands-On Guide to Linux Performance Tools>)
When a dynamically linked application is executed, the Linux loader, ld.so, runs first.ld.so loads all the application’s libraries and connects symbols that the application uses with the functions the libraries provide. Because different libraries were originally linked at different and possibly overlapping places in memory, the linker needs to sort through all the symbols and make sure that each lives at a different place in memory. When a symbol is moved from one virtual address to another, this is called a relocation. It takes time for the loader to do this, and it is much better if it does not need to be done at all. The prelink application aims to do that by rearranging the system libraries of the entire systems so that they do not overlap. An application with a high number of relocations may not have been prelinked.
The Linux loader usually runs without any intervention from the user, and by just executing a dynamic program, it is run automatically. Although the execution of the loader is hidden from the user, it still takes time to run and can potentially slow down an application’s startup time. When you ask for loader statistics, the loader shows the amount of work it is doing and enables you to figure out whether it is a bottleneck.
The ld command is invisibly run for every Linux application that uses shared libraries. By setting the appropriate environment variables, we can ask it to dump information about its execution. The following invocation influences ld execution:
env LD_DEBUG=statistics,help LD_DEBUG_OUTPUT=filename <command>