# /usr/ccs/bin/elfdump -d /usr/lib/bdb/db_verify | grep 'R*PATH'
[5]  RUNPATH           0x225               /net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib
[6]  RPATH             0x225               /net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib

I read this and thought about compiling the attached source. But I couldn’t find x86 where google:”SunStudio” or gcc was installed.

Changing ELF Runpaths (Code Included) : Ali Bahrami

A recent change to Solaris ELF files makes it possible to change the google:”runpath” of a dynamic executable

Then I read this.

Introducing elfedit: A Tool For Modifying Existing ELF Objects : Ali Bahrami

elfedit can indeed modify the runpath in an object, but it is considerably more general than that. elfedit is a tool for examining and modifying the ELF metadata that resides within google:”ELF object”s.

So, I extracted google:”elfedit” and related libraries from internal google:”Nevada install” server onto Solaris 10. Maybe I’m showing my ignorance here. I couldn’t make it work on Solaris 10. It could have possibly worked although surely not supported.

So, I decided to hack the binaries. I was a little scared when google:”strings” command didn’t show it.

# /usr/bin/strings /usr/lib/bdb/google:"db_verify" | grep /net

But google:”GNU strings” can show it.

# /usr/sfw/bin/gstrings --target=elf32-i386 db_verify | grep /net
/net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib

I used google:”GNU sed” to google:”stub out” runpath.

# gnused -i.backup 's|\/net/sunserver.loc0a/export/JES/U1/BDB/sbi/20070123.1/builds/solaris_x86/RELEASE/build.4.2.52_solaris_x86_5.10-RELEASE.01.23.2007.0847/usr/lib|                                                                                                                                              |' db_*

Using the Sun Java Communications Suite VMware Image – Sun Java Communications Suite – wikis.sun.com

This image is 64-bit only.

So, when I started this VM on 32-bit machine, DSEE failed to start. I know it. DSEE does not support copying over bdb files over to different platform. Apparently, google:”OpenLDAP” doesn’t either.

RE: BDB, endian

The ID’s do not have a fixed, platform-independent, data-type associated with them, i.e. on 32-bit platforms the ID’s are 32-bit integer values and on 64-bit platforms the ID’s are 64-bit integer values.

But, in the rare hope that it would work, I edited several text files, among which was google:”dse.ldif”. The error finally reduced to __db.001 file. I googled and found a hint at google:”RedHat package management”.

I have used RedHat around 15 years and didn’t know BerkeleyDB was used there.

Bug 486423 – rpmdb locking broken by other-arch rpmquery

it’s deep internals of BDB and contains inherently architecture-dependent data like pointers to memory IIRC

I removed __db.001 files and , finally, DSEE631 32-bit started fine!

But this way of migrating data is not supported. In fact, if index was there or datafile was 8GB large, it may not work.

AFAIK, this is OK with VirtualBox. It enables google:”RDP” be default. So, one can always connect from remote Windows,.. or google:”SunRay”, etc.

Today, I learned VMware doesn’t take care of enabling google:”VNC” remote access. The VM I tried is from:

Communications Suite 7: Installing the VMware Image – Factotum

Communications Suite 7 VMware image is a simple and portable method for demonstrating Communications Suite 7 features without the overhead of installation and configuration.

I started this vm like:

$ vmrun start SunJava_Comms_Suite7u0_VM/*.vmx nogui

I tried to access it from VNC viewer on Windows. Failed… So, what did I do ?

I could have google:”ACPI” shut down this vm pretty much safely like this and configure vnc and restart it.

$ vmrun stop SunJava_Comms_Suite7u0_VM/*.vmx soft

Instead, I chose to ssh into this vm. First, I checked how vm guest network is configured.

$ grep connection SunJava_Comms_Suite7u0_VM/*.vmx
ethernet0.connectionType = "nat"

It’s google:”NAT”. This means it uses google:”VMNet8″ subnet on host. And if guest is set up for DHCP, it would get IP address from dhcp server for vmnet8.

$ grep ethernet.*Address SunJava_Comms_Suite7u0_VM/*.vmx
ethernet0.generatedAddress = "00:0c:29:55:ce:5b"
ethernet0.generatedAddressOffset = "0"
$ grep -B 3 00:0c:29:55:ce:5b /etc/vmware/vmnet8/dhcpd/dhcpd.leases
lease 172.16.128.130 {
starts 3 2010/01/20 05:56:45;
ends 3 2010/01/20 05:56:44;
hardware ethernet 00:0c:29:55:ce:5b;
$ ping -b 172.16.128.255
WARNING: pinging broadcast address
PING 172.16.128.255 (172.16.128.255) 56(84) bytes of data.
64 bytes from 172.16.128.1: icmp_seq=0 ttl=64 time=0.042 ms
64 bytes from 172.16.128.130: icmp_seq=0 ttl=255 time=1.63 ms (DUP!)

Voila! Now, I can ssh.

$ ssh root@172.16.128.130
Warning: Your password has expired, please change it now.
New Password:
Re-enter new Password:
sshd-kbdint: password successfully changed for root
Last login: Tue Dec 15 02:26:34 2009 from 10.1.110.19
Sun Mircosystems Inc.   SunOS 5.10      Generic January 2005
Sun Communications Suite 7
Deployed via the EMRA Toolkit (version 7.0-0.02)
Virtual Machine Built: 12:15:00:44.25-2009
Product: Messaging Server (64bit) 7u3                Version: 7.3-11.01
Product: Comms DSsetup 6.4                           Version: 6.4-5.05
Product: Calendar Server 7                           Version: 7.0-0.26
Product: Instant Messaging 8u2                       Version: 8.2-02.04
Product: Convergence 1u3                             Version: 1.0-10.01
Product: Indexing and Search Service 1.0             Version: 1.0-32.01
Product: Comms Delegated Administrator 7             Version: 7.0-1.00
Product: Calendar Server 6.3                         Version: 6.3-19.01

Nice! I didn’t know that Solaris can set expiration on root password.

NTrace

NTrace uses a novel approach of instrumenting binary code on the fly by leveraging certain aspects of the Microsoft hotpatching infrastructure. This allows NTrace to be both very robust and fast: On x86, NTrace outperforms google:”DTrace” by a factor of almost three!

1. This tool is not yet downloadable.
2. I think this tool is more closer to google:”truss”(google:”strace” on linux) than to google:”dtrace”.
3. The author apparently did a good study on dtrace implementations and explains difference between SPARC and IA-32 in “NTrace: Function Boundary Tracing for Windows on IA-32“.

On Windows, the default thread stack size is read from the binary (java.exe). As of Java SE 6, this value is 320k in the 32-bit VM and 1024k in the 64-bit VM.

So, let’s see it in google!”Cygwin”. Another way to check is with Microsoft’s MSVC “google:”dumpbin” /headers” command.

$ type objdump
objdump is hashed (/usr/bin/objdump)
$ objdump -p /c/d/Program\ Files/Java/jre1.6.0_07/bin/java.exe | grep stack
SizeOfStackReserve      00050000
SizeOfStackCommit       00001000

These values are in hex. So show them in decimal.

$ objdump -p /c/d/Program\ Files/Java/jre1.6.0_07/bin/java.exe | grep stack | cut -f2 | sed 's/^/0x/' | xargs printf "%d %d\n"
327680 4096
$ objdump -p /c/d/Program\ Files/Java/jre1.5.0_16/bin/java.exe | grep stack | cut -f2 | sed 's/^/0x/' | xargs printf "%d %d\n"
262144 4096

So, it’s 256KB in 1.5 and 320KB in 1.6.

OTN Discussion Forums : tkprof …

I have 10 udump trace files generated by batch that run in 10 process.
I would like to merge them into one tkprof file.

I don’t think my solution of using google:”/dev/stdin” is actually supported by oracle. Supported way is to use a Java tool called google:”trcsess” on oracle 10g and up.

Just for the fun of it, I tried using google:”/dev/stdin” on google:”trcsess” command line. It worked! So, here’s my hypothesis of the day:
“Any Java program which takes filename as an argument can read /dev/stdin because Java program doesn’t call lower library functions.”

$ echo *.trc | wc -w
220
$ cat *.trc | wc -l
3391365
$ cat *.trc | tkprof /dev/stdin all.tkprof
$ tail all.tkprof
280  sessions in tracefile.
3150861  user  SQL statements in trace file.
79974  internal SQL statements in trace file.
17923  SQL statements in trace file.
4434  unique SQL statements in trace file.
3391365  lines in trace file.

$ (gzcat orcl_ora_9120.trc.gz && gzcat orcl_ora_9845.trc.gz) | wc -l
6829778
$ (gzcat orcl_ora_9120.trc.gz && gzcat orcl_ora_9845.trc.gz) | tkprof /dev/stdin /tmp/test.tkprof
$ tail /tmp/test.tkprof
3  sessions in tracefile.
50078  user  SQL statements in trace file.
47  internal SQL statements in trace file.
30583  SQL statements in trace file.
8920  unique SQL statements in trace file.
6829778  lines in trace file.
15995  elapsed seconds in trace file.

First I thought I run ping every 6 hours via ‘cron’. But I want to ping more often once server is detected down and until it comes back up.

So, I came up with this self registering ‘at’ script. This begins pinging the server in google:”incremental backoff” intervals once it’s detected down. Starts at 1 minute, and then 2 minutes. 3,4,5… If you replace “+1″ wit “*2″, it will do google:”exponential backoff”. 1,2,4,8,16…

$ cat ~/misc/myServerPing.at
# THISFILE should be full path or relative from $HOME
# Run this in bash by ". {this file}"
THISFILE=misc/myServerPing.at
INTERVAL=1
curl --silent --connect-timeout 8 http://ourserver.sun.com | grep "Our critical page" > /dev/null
if [ $? -ne 0 ]; then
date | mailx -s "Failed ping to ourserver" my.mail.address@sun.com
sed "s/^\(INTERVAL=\)[1-9]*$/\\1$(($INTERVAL+1))/" $THISFILE | at now + $INTERVAL minutes > /dev/null 2>&1
else
at now + 360 minutes  /dev/null 2>&1
fi

UQ WiMAX | WiMAX USB TYPE UD01NA

# 製 品 名    UD01NA
# 製 造 元    NECアクセステクニカ株式会社

今のところ問題なく動いています。ドライバーをインストールために以下の変更をしましたが本当に必要だったかどうか定かではありません。

$ diff $SYSTEMDRIVE/DRV/UD01NA/drxvi314.inf{.orig,}
10c10
 signature="$Windows NT$"

SAP Community Network Forums: Unable to open hprof file on Debian …

on Solaris (and presumably Linux), this is because of an Eclipse bug — the org.eclipse.core.internal.filesystem.local.LocalFileNatives.internalGetFileInfo() method calls the system lstat() function, which is limited to 2GB files

I couldn’t find a patch for this bug but I guess fix is somewhere since this problem has been known for more than a year.
Luckily, for this particular app, 2 work arounds are available which is explained in the SAP forum above.
I tried 1st w/a of giving google:”java heap dump” file name on command line but I’m not sure it worked. I’m now testing 2nd w/a of hacking snapshotHistory.ser and it seems to work.

Maybe I should have used google:”jhat” or NetBeans to begin with.

Here’s info of Eclipse native library called via google:”JNI”. The output only has ‘lstat’ but not ‘lstat64′. I don’t know if this proves Eclipse bug.

$ pldd $(pgrep MemoryAnalyzer) | grep eclipse | while read line; do nm $line | ggrep -E '\|lstat|internalGetFileInfo\>' && echo $line ;done
[72]    |      4732|     296|FUNC |GLOB |0    |9      |Java_org_eclipse_core_internal_filesystem_local_LocalFileNatives_internalGetFileInfo
[87]    |         0|       0|FUNC |GLOB |0    |UNDEF  |lstat
/mat/configuration/org.eclipse.osgi/bundles/69/1/.cp/os/solaris/sparc/liblocalfile_1_0_0.so