1

I tried 30 day trial of dashDB Local. I followed the steps described in the link: https://www.ibm.com/support/knowledgecenter/en/SS6NHC/com.ibm.swg.im.dashdb.doc/admin/linux_deploy.html

  1. I did not create a node configuration file because mine is a SMP setup.

  2. Logged into my docker hub account and pulled the image.

    docker login -u xxx -p yyyyy

    docker pull ibmdashdb/local:latest-linux

The pull took 5 minutes or so. I waited for the image download to complete.

  1. Ran the following command. It completed successfully.

    docker run -d -it --privileged=true --net=host --name=dashDB -v /mnt/clusterfs:/mnt/bludata0 -v /mnt/clusterfs:/mnt/blumeta0 ibmdashdb/local:latest-linux

  2. ran logs command

    docker logs --follow dashDB

This showed dashDB did not start but exited with error code 130

# docker ps -a
CONTAINER ID        IMAGE                          COMMAND             CREATED             STATUS                       PORTS               NAMES
0f008f8e413d        ibmdashdb/local:latest-linux   "/usr/sbin/init"    16 seconds ago      Exited (130) 1 seconds ago                       dashDB
#

logs command shows this:

2017-05-17T17:48:11.285582000Z Detected virtualization docker.
2017-05-17T17:48:11.286078000Z Detected architecture x86-64.
2017-05-17T17:48:11.286481000Z
2017-05-17T17:48:11.294224000Z Welcome to dashDB Local!
2017-05-17T17:48:11.294621000Z
2017-05-17T17:48:11.295022000Z Set hostname to <orion>.
2017-05-17T17:48:11.547189000Z Cannot add dependency job for unit systemd-tmpfiles-clean.timer, ignoring: Unit is masked.
2017-05-17T17:48:11.547619000Z [  OK  ] Reached target Timers.
<snip>
2017-05-17T17:48:13.361610000Z [  OK  ] Started The entrypoint script for initializing dashDB local.
2017-05-17T17:48:19.729980000Z [100209.207731] start_dashDB_local.sh[161]: /usr/lib/dashDB_local_common_functions.sh: line 1816: /tmp/etc_profile-LOCAL.cfg: No such file or directory
2017-05-17T17:48:20.236127000Z [100209.713223] start_dashDB_local.sh[161]: The dashDB Local container's environment is not set up yet.
2017-05-17T17:48:20.275248000Z [  OK  ] Stopped Create Volatile Files and Directories.
<snip>
2017-05-17T17:48:20.737471000Z Sending SIGTERM to remaining processes...
2017-05-17T17:48:20.840909000Z Sending SIGKILL to remaining processes...
2017-05-17T17:48:20.880537000Z Powering off.

So it looks like start_dashDB_local.sh is failing at /usr/lib/dashDB_local_common_functions.sh 1816th line? I exported the image and this is the 1816th line of dashDB_local_common_functions.sh

update_etc_profile()
{
    local runtime_env=$1
    local cfg_file

    # Check if /etc/profile/dashdb_env.sh is already updated
    grep -q BLUMETAHOME /etc/profile.d/dashdb_env.sh
    if [ $? -eq 0 ]; then
        return
    fi
    case "$runtime_env" in
        "AWS" | "V1.5" )   cfg_file="/tmp/etc_profile-V15_AWS.cfg"
        ;;
        "V2.0" )   cfg_file="/tmp/etc_profile-V20.cfg"
        ;;
        "LOCAL" )  # dashDB Local Case and also the default
            cfg_file="/tmp/etc_profile-LOCAL.cfg"
        ;;
        *)  logger_error "Invalid ${runtime_env} value"
            return
        ;;
    esac

I also see /tmp/etc_profile-LOCAL.cfg in the image. Did I miss any step here? I also created /mnt/clusterfs/nodes file ... but it did not help. The same docker run command failed in the same way. Please help.

I am using x86_64 Fedora25.

# docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-common-1.12.6-6.gitae7d637.fc25.x86_64
 Go version:      go1.7.4
 Git commit:      ae7d637/1.12.6
 Built:           Mon Jan 30 16:15:28 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-common-1.12.6-6.gitae7d637.fc25.x86_64
 Go version:      go1.7.4
 Git commit:      ae7d637/1.12.6
 Built:           Mon Jan 30 16:15:28 2017
 OS/Arch:         linux/amd64
#

# cat /etc/fedora-release
Fedora release 25 (Twenty Five)
# uname -r
4.10.15-200.fc25.x86_64
#
Chris Snow
  • 23,813
  • 35
  • 144
  • 309
Jihyun
  • 883
  • 5
  • 17

1 Answers1

2

Thanks for bringing this to our attention. I reached out to our developer team. It seems this is happening because inside the container, tmpfs gets mounted on to /tmp and wipes out all the scripts

We have seen this issue and moving to the latest version of docker seems to fix it. Your docker version commands shows it is an older version.

So please install the latest docker version and retry the deployment of dashdb Local and update here.

Regards Murali

smurali_ibm
  • 46
  • 2