Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Docker installation of "AS ABAP 7.52 SP04" hangs

abo
Active Contributor

Hi.

On a base Debian/testing system, I have downloaded 7.52 SP04 and verified the checksum of all parts, so far so good.

Starting from an empty /var/lib/docker and with dockerd stopped, I added the following /etc/docker/daemon.json:

{ "storage-opt": [ "dm.basesize=60G" ] }   

Additionally, I have executed:

sudo sysctl -w vm.max_map_count=1000000

After that, I started Docker 19.03.13 and verified that it worked with the hello-world example.

With regards to NW,I have found, and tried, a number of slightly different Dockerfiles

but they all hang at the same point and this is the last message I see:

INFO       2020-11-08 14:17:52.945 (root/sapinst) (startInstallation) [iaxxbfile.cpp:594] id=syslib.filesystem.aclSetSucceeded CIaOsFile::chmod_impl(3,0755)

Authorizations set for /sybase/NPL/startase_reset_sa.

At this point, activity appears to stall: CPU load drops to idle and there is no noticeable disk activity. The docker partition only occupies 24% of about 160GB. This happens also without the daemon.json, again starting from scratch.

If I run strace against "sh /sybase/NPL/startase_reset_sa", I see it is stuck waiting for the child process, which is /sybase/NPL/ASE-16_0/bin/dataserver.

Questions:

  • Has anyone else met with this or a similar problem?
  • Is Docker a supported installation method? Or should I, say, try VirtualBox?

Thanks,

Andrea.

12 REPLIES 12

MarcelloUrbani
Active Contributor

Andrea,

I don't know what your problem is but looks kind of similar to the one I have, where the database silently fails, leaving only an error in a log file (don't have a copy available, should spin up a new container)

Weirdly, on a laptop is working fine, on the other worked for a year or so then dies a few months ago.

The error is in file

/sybase/NPL/ASE-16_0/install/NPL.log, about 30 lines before the end

servicedesk2_
Discoverer
0 Kudos

Here is more information:

00:0000:00000:00000:2020/11/09 16:12:00.91 kernel  SySAM: Using licenses from: /sybase/NPL/SYSAM-2_0/licenses/SYBASE_ASE_TestDrive.lic
00:0000:00000:00000:2020/11/09 16:12:00.97 kernel  SySAM: Checked out license for 4 ASE_CORE (2021.0331/31-mar-2021/1A92 9318 1818 AAFA) will expire Thu 01 Apr 2021 12:00:00 AM UTC.
00:0000:00000:00000:2020/11/09 16:12:00.99 kernel  SySAM: Checked out license for 4 ASE_PARTITIONS (2021.0331/31-mar-2021/1A92 9318 1818 AAFA) will expire Thu 01 Apr 2021 12:00:00 AM UTC.
00:0000:00000:00000:2020/11/09 16:12:01.00 kernel  SySAM: Checked out license for 4 ASE_COMPRESSION (2021.0331/31-mar-2021/1A92 9318 1818 AAFA) will expire Thu 01 Apr 2021 12:00:00 AM UTC.
00:0000:00000:00000:2020/11/09 16:12:01.00 kernel  SySAM: Checked out license for 4 ASE_ASM (2021.0331/31-mar-2021/1A92 9318 1818 AAFA) will expire Thu 01 Apr 2021 12:00:00 AM UTC.
00:0000:00000:00000:2020/11/09 16:12:01.00 kernel  SySAM: Checked out license for 4 ASE_PRIVACY (2021.0331/31-mar-2021/1A92 9318 1818 AAFA) will expire Thu 01 Apr 2021 12:00:00 AM UTC.

TLDR: license is valid.

The final part of the log file:

00:0000:00000:00000:2020/11/09 16:12:01.36 kernel  Loaded encryption provider CommonCryptoLib 8.5.21 (), with FIPS Certified CryptoKernel version 8.4.47.
00:0000:00000:00000:2020/11/09 16:12:01.36 kernel  INFORMATION: The FIPS Certified Crypto Kernel is enabled.
00:0000:00000:00000:2020/11/09 16:12:01.36 kernel  Begin processing to generate RSA keypair.
00:0000:00000:00000:2020/11/09 16:12:01.39 kernel  Completed processing to generate RSA keypair.
00:0002:00000:00000:2020/11/09 16:12:01.39 kernel  ASE - Dynamic Pluggable Component Interface is disabled
00:0002:00000:00000:2020/11/09 16:12:01.39 kernel  Thread 2 (LWP 2279) of Threadpool syb_default_pool online as engine 0
00:0002:00000:00000:2020/11/09 16:12:01.39 kernel  bucket manager consolidator online
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  Current process (0x110009) infected with signal 11 (SIGSEGV)
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  Current Process is running on Engine 0
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  Address 0x0x00007fde84089380 (), siginfo (code, address) = (2, 0x0x00007fde84089380)
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  **** Saved signal context (0x0x000000014bda2e80): ****
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  uc_flags: 0x7, uc_link: 0x(nil)
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  uc_sigmask: 0x7bfbf037 0xb 0x2 0x84089380
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  uc_stack: ss_sp: 0x(nil), ss_size: 0x0, ss_flags: 0x2
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  General Registers (uc_mcontext.gregs):
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       PC : 0x00007fde84089380 ()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel          RAX : 0x00007fde84089380  RBX : 0x00007fde8400c360
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel          RCX : 0x00007fde84093ce0  RDX : 0x00007fde84000a28
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       RBP : 0x000000014bda3f70  RSP : 0x000000014bda3428
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       R8  : 0x00007fde841437a0  R9  : (nil)
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       R10 : 0x0000000000000001  R11 : 0x00007fde91a73490
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       R12 : 0x00007fde84089380  R13 : 0x00007fde84002270
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       R14 : 0x000000014bda39b0  R15 : 0x000000014bda39a0
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       RDI : 0x00007fde926d0540  RSI : 0x000000000000002d
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       RIP : 0x00007fde84089380  CSGSFS : 0x002b000000000033
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       TRAPNO : 0x000000000000000e  ERR : 0x0000000000000015
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel       EFL : 0x0000000000010202
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  **** end of signal context ****
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x00000000015240c0 pcstkwalk+0x482()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x0000000001523a7f ucstkgentrace+0x20f()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x00000000015202b2 ucbacktrace+0x54()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x00000000017ee7fc terminate_process+0x1a1c()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x000000000155078c kisignal+0x706()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x00007fde84089380 ()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x00000000021a2f1b Snap::Validate()+0x3b()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x0000000001828f5d SnapValidation+0xfd()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  pc: 0x00000000008d70e6 dsinit+0x1776()
00:0002:00000:00000:2020/11/09 16:12:01.43 kernel  end of stack trace, kernel service process: kpid 1114121

Not sure what to make of it, though.

MarcelloUrbani
Active Contributor

...or save even more with Alexander Tsybulsky's vagrant script

PS: docker uses a lot less memory (say 1.5 Gb vs ~6), not a bad idea when it works out of the box. When it doesn't can be pretty tough

abo
Active Contributor

By all means, just be prepared to quickly fall back to the official guide if things don't work as expected.

emel
Explorer
0 Kudos

I stumbled upon your post after running into the same problem. Do you by any chance remember how much RAM had the host (not guest VM) you tried this on? Having found SIGSEGV in the logs, my only guess is that this could be memory-related - it looks like the database server is trying to come up for the first time around that point in time of the installation. FWIW, I was trying this (Docker in Ubuntu) on the host with 8GB RAM and that might be too low. I was successful after installing this in vanilla openSUSE WSL2 instance (without Docker) with 16GB host RAM.

abo
Active Contributor
0 Kudos

The host has 16GB of RAM so I don't think this was a low-mem issue: with Virtualbox runs just fine in 6GB max.

abo
Active Contributor
0 Kudos

Former Member interesting finding! I'm not sure what kernel version I had back then but right now I have 5.10.x, which seems to be fine as far as HANA 1909 is concerned. True, I did not have to build that image, SAP did that.

Former Member
0 Kudos

Hi Andrea,

the kernel is yours, as it comes actually with the Linux distribution. Today I was bored and decided to try the 1909 Trial. Installed it on Docker/WSL2. My first Docker experience, and WSL, too. Yes HANA is happy with newer kernels, opposite to ASE.

vhcala4hci:/ # uname -r
5.4.72-microsoft-standard-WSL2

abo
Active Contributor

Former Member

I know, I know. What I meant is that I did not think of writing the kernel version in the question and now so much time has passed that I'd have to spend even more time finding out which version I likely had back then.

murbani

Which version do you have in your image? If it's older than 5.4.x I guess Robert's comment should be promoted to answer.

MarcelloUrbani
Active Contributor

Agreed

I'm on a rolling distribution, I update my kernel weekly

Dates make sense

I think it's still working on my older computer though, so might be hardware dependent

abo
Active Contributor
0 Kudos

Former Member please convert your comment on kernel versions to answer, I'll accept that one instead of mine.

Former Member
0 Kudos

Thank you Andrea. Comment is converted.