Wed, Nov 11, 2009

tech DB2 settings

Posted at 11:51 pm MST to Technology

After a lot of thrashing with DB2 partially working, I finally dug out some DB2 error codes that were googleable.

SQL1084C Shared memory segments cannot be allocated. SQLSTATE=57019

SQL5043N Support for one or more communications protocols failed to start successfully. However, core database manager functionality started successfully.

The first problem, which was preventing runing of most of the dtabases on ykchaua itself, turned out to be shared memory limits inthe OS.

Running "sysctl -w kernel.shmmax=2147483648" seems to have made DB2 runnable on the server, but may be overkill. Checking some old backups, I found a section in sysctl.conf like:

kernel.shmmax = 1610612736
kernel.sem = 250 256000 32 2048
 kernel.msgmnb = 65536
 kernel.msgmni = 16384
 kernel.msgmax = 65536
 kernel.shmmni = 4096
 kernel.shmall = 3774873

The existing values (for the values other than shmmax are) :

kernel.sem = 250     32000   32      1024
 kernel.msgmnb = 65536
 kernel.msgmni = 1680
 kernel.msgmax = 65535
 kernel.shmmni = 4096
 kernel.shmall = 2097152

So I added the block back into the new /etc/sysctl.conf. And this time I commented the changes (which were probably made automatically when I first installed DB2) as DB2 related, so they are less likely to get lost again in the future. Having sysctl.conf set up should make the fix last across reboots.

The other error message I was receiving turned out to be because of a missing entry in /etc/services -- another case of updates stepping on config files.

After appending "db2c_db2inst1 50000/tcp # DB2 first instance" to /etc/services, DB2 seems to be running cleanly on ykchaua. Finally.

And....

My applications in the Windows images are able to connect... technically. I was able to configure the connections without error messages, But I can't seem to login to the apps, and the error messages are not being helpful.

permanent link || trackback || 0 comments || Add a comment

tech WICD

Posted at 1:07 pm MST to Technology

In my ongoing quest to get samba working again with the vmware images, I realized that part of the problem may be that the network was not getting set up soon enough at boot time. (Samba worked for a couple of days after I get it set up, but I'm nt sure it came back after the next reboot.) The vmware images were coming up with their network connections in strange states after the main machine rebooted, which seemed suspicious... or at least unhelpful.

The NetworkManager tool that comes with Karmic Kubuntu was not setting up the link until after I logged into the X window system. This could be a problem for samba because the authentication module that wanted to talk to the Active Directory server could not reach it until networking was running and vmware was up. Getting the networking stack to be active as soon as possible after boot would help the handshaking initialize properly.

The lack of a working network at boot time may be making DB2 unhappy, too.

I had given up on Network Manager completely in previous OS versions. But that meant I needed to manually edit the /etc/network/interfaces file whenever I needed to use the wireless connector in a different environment -- at the office, or a hotel, for example.

I hoped there was a way to make my wireless connection more flexible, even with the vmware subnet bridged off it. One of these days I want to get wired ethernet run to the livingroom and bedroom from the study where the DSL modem and router live, but for now I need to use the wireless connection for things it's not really configured for.

A bit of googling suggested that a tool called "wicd" would provide connect-at-boot, and also the flexibility to support some of the fairly strange networking requirements I have. I haven't tried a wired connection with it yet, but the wireless one seems to be doing what I wanted it to.

So far, so good.

Next step, get the samba permissions working again. Then get DB2 up. Then do the development and testing I'm really supposed to be working on.

permanent link || trackback || 0 comments || Add a comment

tech VMWare 202

Posted at 12:58 am MST to Technology

I refreshed the kernel modules (which should have just reinstalled the same stuff) and upgraded VMWare server to 2.0.2 and updated the vmware tools in all the guest OSs. VMWare seems to be working again now.

Samba permissions are still flaking out but I'll deal with that after I've slept.

I noticed when I was refreshing the kernel modules that even though I used an i386 installation disk, kubuntu seems to be using the x86/64 kernel modules. If I have any more problems, I should proably try to force it over to the i386 versions. I'm not entirely sure how to go about doing that safely.

permanent link || trackback || 0 comments || Add a comment