Headless runtime image crashes on startup on headless server

Joachim,

I recall that OS Error 1 is a "Function not found". If that's the
case, it implies that the library was indeed found, but an entry point
for the function was not found.

Doug Swartz

Saturday, April 14, 2012, 10:59:28 AM, you wrote:

> Hi Marten,

> It's really a Server in the cloud-no GUI.
> On a Vm with X Windows and the same Db2 installation there is no
> problem running the code, both in the IDE and packaged geadlessly.

> In the meantime, I've checked that libdb2.so  is in the path and the same version as "at home".

> Joachim

Hi Doug,

I am not fully sure but tend to agree. The problem really is a failed primitive when trying to call SQLAllocEnv.

Interestingly, SQLAllocEnv shouldn't be called at all. Right before the SQLAllocEnv call VAST tries to determine if it should use SQLAllocEnv (deprecated with ODBC3) or SQLAllocHandle (see AbtOdbcDatabaseManager>>allocateEnvironmentHandle). This is determined by calling 

(AbtIbmCliDatabaseManager platformFunctions at: AbtOdbcPlatformFunctions::OdbcSQLAllocHandle) abtValidAddress

and the question whether an address is valid is answered by asking the library for the address of an entry point. On my test VM the above statement answers true (the platform function there is <c: int32 'libdb2.so':SQLAllocHandle uint16 uint32 struct>) . 

This means that the library seems to be unaccessible or not found. On the other hand, shouldn't the getAddress: call on an unfound library trigger OS Error 126? If so, it would mean the library is found...

So I am not really any further. Since I tried running the image as both root and the db2 instance owner, and both get the same error, I believe it's not a file permission problem. Both users start the image with the same start script, and root's LD_LIBRARY_PATH does not contain any entries before running the start script. So at least root is not trying to access the lib64 version of libdb2.so.

Does anybody have any idea how to dig into this problem and find the cause?

Joachim

Am Sonntag, 15. April 2012 04:23:04 UTC+2 schrieb dswartz:

Joachim,

I recall that OS Error 1 is a "Function not found". If that's the
case, it implies that the library was indeed found, but an entry point
for the function was not found.

Doug Swartz

Saturday, April 14, 2012, 10:59:28 AM, you wrote:

> Hi Marten,

> It's really a Server in the cloud-no GUI.
> On a Vm with X Windows and the same Db2 installation there is no
> problem running the code, both in the IDE and packaged geadlessly.

> In the meantime, I've checked that libdb2.so  is in the path and the same version as "at home".

> Joachim

Hi again,

here's an excerpt from the walk back.log:

PlatformFunction(Object)>>#error:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 'Primitive failed in: PlatformFunction>>#callWithArguments: due to OS error1'

PlatformFunction(Object)>>#primitiveFailed:withArgument:backUp:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 18

  arg2 = 1

  arg3 = 1

PlatformFunction(Object)>>#primitiveFailed

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

PlatformFunction>>#callWithArguments:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

PlatformFunction>>#callWithArray:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#callPlatformFunction:withArray:useThreadPreference:threadKey:

  receiver = an AbtIbmCliDatabaseManager

  arg1 = 2

  arg2 = ([0 0 0 0])

  arg3 = true

  arg4 = nil

  temp1 = nil

  temp2 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#allocateEnvironmentHandle

  receiver = an AbtIbmCliDatabaseManager

  temp1 = [0 0 0 0]

  temp2 = 2

  temp3 = ([0 0 0 0])

  temp4 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#initialize

  receiver = an AbtIbmCliDatabaseManager

Am Sonntag, 15. April 2012 08:00:14 UTC+2 schrieb [hidden email]:

Hi Doug,

I am not fully sure but tend to agree. The problem really is a failed primitive when trying to call SQLAllocEnv.

Interestingly, SQLAllocEnv shouldn't be called at all. Right before the SQLAllocEnv call VAST tries to determine if it should use SQLAllocEnv (deprecated with ODBC3) or SQLAllocHandle (see AbtOdbcDatabaseManager>>allocateEnvironmentHandle). This is determined by calling 

(AbtIbmCliDatabaseManager platformFunctions at: AbtOdbcPlatformFunctions::OdbcSQLAllocHandle) abtValidAddress

and the question whether an address is valid is answered by asking the library for the address of an entry point. On my test VM the above statement answers true (the platform function there is <c: int32 'libdb2.so':SQLAllocHandle uint16 uint32 struct>) . 

This means that the library seems to be unaccessible or not found. On the other hand, shouldn't the getAddress: call on an unfound library trigger OS Error 126? If so, it would mean the library is found...

So I am not really any further. Since I tried running the image as both root and the db2 instance owner, and both get the same error, I believe it's not a file permission problem. Both users start the image with the same start script, and root's LD_LIBRARY_PATH does not contain any entries before running the start script. So at least root is not trying to access the lib64 version of libdb2.so.

Does anybody have any idea how to dig into this problem and find the cause?

Joachim

Am Sonntag, 15. April 2012 04:23:04 UTC+2 schrieb dswartz:

Joachim,

I recall that OS Error 1 is a "Function not found". If that's the
case, it implies that the library was indeed found, but an entry point
for the function was not found.

Doug Swartz

Saturday, April 14, 2012, 10:59:28 AM, you wrote:

> Hi Marten,

> It's really a Server in the cloud-no GUI.
> On a Vm with X Windows and the same Db2 installation there is no
> problem running the code, both in the IDE and packaged geadlessly.

> In the meantime, I've checked that libdb2.so  is in the path and the same version as "at home".

> Joachim

I finally "found" the solution. The Linux installation missed some 32-Bit libraries.

openSuse does not come with a handy bundle like Ubuntu's ia32-lib package, so after a few iterations of installing more and more 32 bit libraries, I have no real clue which one(s) exactly was / were missing. It was none that sounded like it is important. But it was, obviously.

I still wonder how I could have found out other than trial & error. Over at the db2 google group, somebody suggested using strace. I'll try to find out more about it when I get the time...

Joachim

Am Montag, 16. April 2012 14:54:25 UTC+2 schrieb [hidden email]:

Hi again,

here's an excerpt from the walk back.log:

PlatformFunction(Object)>>#error:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 'Primitive failed in: PlatformFunction>>#callWithArguments: due to OS error1'

PlatformFunction(Object)>>#primitiveFailed:withArgument:backUp:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 18

  arg2 = 1

  arg3 = 1

PlatformFunction(Object)>>#primitiveFailed

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

PlatformFunction>>#callWithArguments:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

PlatformFunction>>#callWithArray:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#callPlatformFunction:withArray:useThreadPreference:threadKey:

  receiver = an AbtIbmCliDatabaseManager

  arg1 = 2

  arg2 = ([0 0 0 0])

  arg3 = true

  arg4 = nil

  temp1 = nil

  temp2 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#allocateEnvironmentHandle

  receiver = an AbtIbmCliDatabaseManager

  temp1 = [0 0 0 0]

  temp2 = 2

  temp3 = ([0 0 0 0])

  temp4 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#initialize

  receiver = an AbtIbmCliDatabaseManager

Am Sonntag, 15. April 2012 08:00:14 UTC+2 schrieb [hidden email]:

Hi Doug,

I am not fully sure but tend to agree. The problem really is a failed primitive when trying to call SQLAllocEnv.

Interestingly, SQLAllocEnv shouldn't be called at all. Right before the SQLAllocEnv call VAST tries to determine if it should use SQLAllocEnv (deprecated with ODBC3) or SQLAllocHandle (see AbtOdbcDatabaseManager>>allocateEnvironmentHandle). This is determined by calling 

(AbtIbmCliDatabaseManager platformFunctions at: AbtOdbcPlatformFunctions::OdbcSQLAllocHandle) abtValidAddress

and the question whether an address is valid is answered by asking the library for the address of an entry point. On my test VM the above statement answers true (the platform function there is <c: int32 'libdb2.so':SQLAllocHandle uint16 uint32 struct>) . 

This means that the library seems to be unaccessible or not found. On the other hand, shouldn't the getAddress: call on an unfound library trigger OS Error 126? If so, it would mean the library is found...

So I am not really any further. Since I tried running the image as both root and the db2 instance owner, and both get the same error, I believe it's not a file permission problem. Both users start the image with the same start script, and root's LD_LIBRARY_PATH does not contain any entries before running the start script. So at least root is not trying to access the lib64 version of libdb2.so.

Does anybody have any idea how to dig into this problem and find the cause?

Joachim

Am Sonntag, 15. April 2012 04:23:04 UTC+2 schrieb dswartz:

Joachim,

I recall that OS Error 1 is a "Function not found". If that's the
case, it implies that the library was indeed found, but an entry point
for the function was not found.

Doug Swartz

Saturday, April 14, 2012, 10:59:28 AM, you wrote:

> Hi Marten,

> It's really a Server in the cloud-no GUI.
> On a Vm with X Windows and the same Db2 installation there is no
> problem running the code, both in the IDE and packaged geadlessly.

> In the meantime, I've checked that libdb2.so  is in the path and the same version as "at home".

> Joachim

Hi,

I had to setup a new Ubuntu 12.04 Server (64 bit) and had the same problem again. The package that was missing was libpam-modules:i386. This solved the issue.

Since Ubuntu is a supported platform (does that apply to 64 bit as well?): Maybe it would be good if Instantiations assembled a list of packages that are required. This should of course also be true for other supported Linux platforms. 

Here's a short list of things that I found you need on Ubuntu 12.04 (64):

ia32-libs

binutils

libpam-modules:i386

libaio (maybe this one is not required by VAST, I need it for DB2, however)

Joachim


Am Montag, 16. April 2012 21:22:31 UTC+2 schrieb [hidden email]:

I finally "found" the solution. The Linux installation missed some 32-Bit libraries.

openSuse does not come with a handy bundle like Ubuntu's ia32-lib package, so after a few iterations of installing more and more 32 bit libraries, I have no real clue which one(s) exactly was / were missing. It was none that sounded like it is important. But it was, obviously.

I still wonder how I could have found out other than trial & error. Over at the db2 google group, somebody suggested using strace. I'll try to find out more about it when I get the time...

Joachim

Am Montag, 16. April 2012 14:54:25 UTC+2 schrieb [hidden email]:

Hi again,

here's an excerpt from the walk back.log:

PlatformFunction(Object)>>#error:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 'Primitive failed in: PlatformFunction>>#callWithArguments: due to OS error1'

PlatformFunction(Object)>>#primitiveFailed:withArgument:backUp:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 18

  arg2 = 1

  arg3 = 1

PlatformFunction(Object)>>#primitiveFailed

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

PlatformFunction>>#callWithArguments:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

PlatformFunction>>#callWithArray:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#callPlatformFunction:withArray:useThreadPreference:threadKey:

  receiver = an AbtIbmCliDatabaseManager

  arg1 = 2

  arg2 = ([0 0 0 0])

  arg3 = true

  arg4 = nil

  temp1 = nil

  temp2 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#allocateEnvironmentHandle

  receiver = an AbtIbmCliDatabaseManager

  temp1 = [0 0 0 0]

  temp2 = 2

  temp3 = ([0 0 0 0])

  temp4 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#initialize

  receiver = an AbtIbmCliDatabaseManager

Am Sonntag, 15. April 2012 08:00:14 UTC+2 schrieb [hidden email]:

Hi Doug,

I am not fully sure but tend to agree. The problem really is a failed primitive when trying to call SQLAllocEnv.

Interestingly, SQLAllocEnv shouldn't be called at all. Right before the SQLAllocEnv call VAST tries to determine if it should use SQLAllocEnv (deprecated with ODBC3) or SQLAllocHandle (see AbtOdbcDatabaseManager>>allocateEnvironmentHandle). This is determined by calling 

(AbtIbmCliDatabaseManager platformFunctions at: AbtOdbcPlatformFunctions::OdbcSQLAllocHandle) abtValidAddress

and the question whether an address is valid is answered by asking the library for the address of an entry point. On my test VM the above statement answers true (the platform function there is <c: int32 'libdb2.so':SQLAllocHandle uint16 uint32 struct>) . 

This means that the library seems to be unaccessible or not found. On the other hand, shouldn't the getAddress: call on an unfound library trigger OS Error 126? If so, it would mean the library is found...

So I am not really any further. Since I tried running the image as both root and the db2 instance owner, and both get the same error, I believe it's not a file permission problem. Both users start the image with the same start script, and root's LD_LIBRARY_PATH does not contain any entries before running the start script. So at least root is not trying to access the lib64 version of libdb2.so.

Does anybody have any idea how to dig into this problem and find the cause?

Joachim

Am Sonntag, 15. April 2012 04:23:04 UTC+2 schrieb dswartz:

Joachim,

I recall that OS Error 1 is a "Function not found". If that's the
case, it implies that the library was indeed found, but an entry point
for the function was not found.

Doug Swartz

Saturday, April 14, 2012, 10:59:28 AM, you wrote:

> Hi Marten,

> It's really a Server in the cloud-no GUI.
> On a Vm with X Windows and the same Db2 installation there is no
> problem running the code, both in the IDE and packaged geadlessly.

> In the meantime, I've checked that libdb2.so  is in the path and the same version as "at home".

> Joachim

Well, actually, yes, something like that ;-) 

Thanks for the pointer. Now I know that I have all that's needed. Makes me feel much better.

So I expected this bit of information in the Installation Guide and admit to ignore the FAQ way too much ;-)

While we're at it: the FAQ you link to says libpam-modules:i386 was required for emsrv. That cannot be true. The machine I am deploying to neither runs emsrv nor a development image. it really is a production server and runs only a headless runtime image. The faq might imply that the package is not required if you don't need emsrv.

Then there is this other thing that doesn't calm down in my brain: couldn't the error message be more helpful? I mean, the problem is completely unrelated to libdb2.so. There is some library missing that should be there for something between the VM and libdb2. So it would be nice if the VM told me more about what is wrong. The error as it stands implies a problem with libdb2.so. Unfortunately, my knowledge in such low level C programming isn't sufficient to suggest a concrete solution...

Joachim

Am Freitag, 21. Juni 2013 21:30:20 UTC+2 schrieb John O'Keefe:

Joachim -

Do you mean something like this FAQ page: Q: How do I prepare a 64-bit Linux machine to run VA Smalltalk?

John

On Friday, June 21, 2013 1:39:21 AM UTC-4, [hidden email] wrote:

Hi,

I had to setup a new Ubuntu 12.04 Server (64 bit) and had the same problem again. The package that was missing was libpam-modules:i386. This solved the issue.

Since Ubuntu is a supported platform (does that apply to 64 bit as well?): Maybe it would be good if Instantiations assembled a list of packages that are required. This should of course also be true for other supported Linux platforms. 

Here's a short list of things that I found you need on Ubuntu 12.04 (64):

ia32-libs

binutils

libpam-modules:i386

libaio (maybe this one is not required by VAST, I need it for DB2, however)

Joachim


Am Montag, 16. April 2012 21:22:31 UTC+2 schrieb [hidden email]:

I finally "found" the solution. The Linux installation missed some 32-Bit libraries.

openSuse does not come with a handy bundle like Ubuntu's ia32-lib package, so after a few iterations of installing more and more 32 bit libraries, I have no real clue which one(s) exactly was / were missing. It was none that sounded like it is important. But it was, obviously.

I still wonder how I could have found out other than trial & error. Over at the db2 google group, somebody suggested using strace. I'll try to find out more about it when I get the time...

Joachim

Am Montag, 16. April 2012 14:54:25 UTC+2 schrieb [hidden email]:

Hi again,

here's an excerpt from the walk back.log:

PlatformFunction(Object)>>#error:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 'Primitive failed in: PlatformFunction>>#callWithArguments: due to OS error1'

PlatformFunction(Object)>>#primitiveFailed:withArgument:backUp:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = 18

  arg2 = 1

  arg3 = 1

PlatformFunction(Object)>>#primitiveFailed

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

PlatformFunction>>#callWithArguments:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

PlatformFunction>>#callWithArray:

  receiver = <c: int32 'libdb2.so':SQLAllocEnv struct>

  arg1 = ([0 0 0 0])

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#callPlatformFunction:withArray:useThreadPreference:threadKey:

  receiver = an AbtIbmCliDatabaseManager

  arg1 = 2

  arg2 = ([0 0 0 0])

  arg3 = true

  arg4 = nil

  temp1 = nil

  temp2 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#allocateEnvironmentHandle

  receiver = an AbtIbmCliDatabaseManager

  temp1 = [0 0 0 0]

  temp2 = 2

  temp3 = ([0 0 0 0])

  temp4 = nil

AbtIbmCliDatabaseManager(AbtOdbcDatabaseManager)>>#initialize

  receiver = an AbtIbmCliDatabaseManager

Am Sonntag, 15. April 2012 08:00:14 UTC+2 schrieb [hidden email]:

Hi Doug,

I am not fully sure but tend to agree. The problem really is a failed primitive when trying to call SQLAllocEnv.

Interestingly, SQLAllocEnv shouldn't be called at all. Right before the SQLAllocEnv call VAST tries to determine if it should use SQLAllocEnv (deprecated with ODBC3) or SQLAllocHandle (see AbtOdbcDatabaseManager>>allocateEnvironmentHandle). This is determined by calling 

(AbtIbmCliDatabaseManager platformFunctions at: AbtOdbcPlatformFunctions::OdbcSQLAllocHandle) abtValidAddress

and the question whether an address is valid is answered by asking the library for the address of an entry point. On my test VM the above statement answers true (the platform function there is <c: int32 'libdb2.so':SQLAllocHandle uint16 uint32 struct>) . 

This means that the library seems to be unaccessible or not found. On the other hand, shouldn't the getAddress: call on an unfound library trigger OS Error 126? If so, it would mean the library is found...

So I am not really any further. Since I tried running the image as both root and the db2 instance owner, and both get the same error, I believe it's not a file permission problem. Both users start the image with the same start script, and root's LD_LIBRARY_PATH does not contain any entries before running the start script. So at least root is not trying to access the lib64 version of libdb2.so.

Does anybody have any idea how to dig into this problem and find the cause?

Joachim

Am Sonntag, 15. April 2012 04:23:04 UTC+2 schrieb dswartz:

Joachim,

I recall that OS Error 1 is a "Function not found". If that's the
case, it implies that the library was indeed found, but an entry point
for the function was not found.

Doug Swartz

Saturday, April 14, 2012, 10:59:28 AM, you wrote:

> Hi Marten,

> It's really a Server in the cloud-no GUI.
> On a Vm with X Windows and the same Db2 installation there is no
> problem running the code, both in the IDE and packaged geadlessly.

> In the meantime, I've checked that libdb2.so  is in the path and the same version as "at home".

> Joachim

While we're at it: the FAQ you link to says libpam-modules:i386 was required for emsrv. That cannot be true. The machine I am deploying to neither runs emsrv nor a development image. it really is a production server and runs only a headless runtime image. The faq might imply that the package is not required if you don't need emsrv.

Joachim

Joachim -

We can document what we know. We know that EMSRV can use PAM and when it does, it needs libpam-modules:i386. We do not know what other components (such as a DB manager) used in your run time may also require PAM. But I do take your point and I will update the FAQ page to indicate that other components may require PAM and users should refer to the documentation of these other components for further information.

John

On Sunday, June 23, 2013 3:37:28 AM UTC-4, [hidden email] wrote:

While we're at it: the FAQ you link to says libpam-modules:i386 was required for emsrv. That cannot be true. The machine I am deploying to neither runs emsrv nor a development image. it really is a production server and runs only a headless runtime image. The faq might imply that the package is not required if you don't need emsrv.

Joachim