DB2 Client in Docker
up vote
1
down vote
favorite
We have the need to create a docker container that also has the db2 client installed. This container will also have some shell scripts that make use of the db2 client.
We take a base Cent OS image and then add db2 via a RUN command:
COPY db2rtcl_nr.rsp /db2install/
RUN cd /db2install && curl -o ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz http://public_file_server.com/downloads/appTools/installs/db2/ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
tar -xvf ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rm -f ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rtcl/db2setup -u db2rtcl_nr.rsp -f sysreq &&
chown -R 1000:1000 /opt/ibm/db2/V11.1
ENV PATH="$PATH:/opt/ibm/db2/V11.1/bin"
The image builds ok with no errors.
However, when I try running and connecting to the container via interactive shell command:
docker run -it --entrypoint=/bin/bash db2Container
and try to invoke the db2 CLI with
db2
I get the error:
DB21018E A system error occurred. The command line processor could not
continue processing.
Whats confusing is that if I immediately run a bash
shell and then invoke the db2
CLI, it works:
bash
db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 11.1.0
You can issue database manager commands and SQL statements from the command
prompt. For example:
db2 => connect to sample
db2 => bind sample.bnd
For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
? CATALOG DATABASE for help on the CATALOG DATABASE command
? CATALOG for help on all of the CATALOG commands.
To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.
For more detailed help, refer to the Online Reference Manual.
db2 =>
Things I have tried to diagnose the issue:
When I 1st drop into the interactive shell session, I type
env > /tmp/env1.txt
I then typebash
and run
env > /tmp/env2.txt
When Idiff
the files, they are virtually identical EXCEPT for the variable:
SHLVL=2
which I know is just indicating that the 2nd shell is a nested shellWhen I 1st drop into the interactive shell session, I type
set > /tmp/set1.txt
I then typebash
and run
set > /tmp/set2.txt
When Idiff
the files, they are virtually identical EXCEPT for theSHLVL
variable again
Why is the db2 CLI accessible after I bash
in the container but not in the initial session when i have used docker run -it
?
We are attempting to use this container as an executable container that has the db2 client in it to connect to external DB2 databases. We are NOT trying to run a db2 DB in a container.
What I am starting to find is that I might have an issue with how the entrypoint is defined in our Dockerfile.
Using:
ENTRYPOINT cat /dev/null && /usr/bin/bash
the DB2 client is available when I run docker run -it ContainerName
without having to immediately type bash
BUT it does not work when I try to run the container as an executable docker run ContainerName
The closest I have come to the solution is this modification to the Dockerfile:
ENTRYPOINT
CMD ["/bin/bash"]
When I run the container as an executable docker run ContainerName db2 list command options
it works however NOW if I docker run -it ContainerName
I dont immediately have db2
commands available without typing bash
once. This is still problematic since this container will have shell script in it that need to be able to run db2 commands
docker db2
|
show 1 more comment
up vote
1
down vote
favorite
We have the need to create a docker container that also has the db2 client installed. This container will also have some shell scripts that make use of the db2 client.
We take a base Cent OS image and then add db2 via a RUN command:
COPY db2rtcl_nr.rsp /db2install/
RUN cd /db2install && curl -o ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz http://public_file_server.com/downloads/appTools/installs/db2/ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
tar -xvf ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rm -f ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rtcl/db2setup -u db2rtcl_nr.rsp -f sysreq &&
chown -R 1000:1000 /opt/ibm/db2/V11.1
ENV PATH="$PATH:/opt/ibm/db2/V11.1/bin"
The image builds ok with no errors.
However, when I try running and connecting to the container via interactive shell command:
docker run -it --entrypoint=/bin/bash db2Container
and try to invoke the db2 CLI with
db2
I get the error:
DB21018E A system error occurred. The command line processor could not
continue processing.
Whats confusing is that if I immediately run a bash
shell and then invoke the db2
CLI, it works:
bash
db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 11.1.0
You can issue database manager commands and SQL statements from the command
prompt. For example:
db2 => connect to sample
db2 => bind sample.bnd
For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
? CATALOG DATABASE for help on the CATALOG DATABASE command
? CATALOG for help on all of the CATALOG commands.
To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.
For more detailed help, refer to the Online Reference Manual.
db2 =>
Things I have tried to diagnose the issue:
When I 1st drop into the interactive shell session, I type
env > /tmp/env1.txt
I then typebash
and run
env > /tmp/env2.txt
When Idiff
the files, they are virtually identical EXCEPT for the variable:
SHLVL=2
which I know is just indicating that the 2nd shell is a nested shellWhen I 1st drop into the interactive shell session, I type
set > /tmp/set1.txt
I then typebash
and run
set > /tmp/set2.txt
When Idiff
the files, they are virtually identical EXCEPT for theSHLVL
variable again
Why is the db2 CLI accessible after I bash
in the container but not in the initial session when i have used docker run -it
?
We are attempting to use this container as an executable container that has the db2 client in it to connect to external DB2 databases. We are NOT trying to run a db2 DB in a container.
What I am starting to find is that I might have an issue with how the entrypoint is defined in our Dockerfile.
Using:
ENTRYPOINT cat /dev/null && /usr/bin/bash
the DB2 client is available when I run docker run -it ContainerName
without having to immediately type bash
BUT it does not work when I try to run the container as an executable docker run ContainerName
The closest I have come to the solution is this modification to the Dockerfile:
ENTRYPOINT
CMD ["/bin/bash"]
When I run the container as an executable docker run ContainerName db2 list command options
it works however NOW if I docker run -it ContainerName
I dont immediately have db2
commands available without typing bash
once. This is still problematic since this container will have shell script in it that need to be able to run db2 commands
docker db2
Does it make a difference if you explicitly dot in the db2profile before you run the CLP? If it does, either the wrong startup profile is running, or that startup profile has'nt been properly updated, or is not running correctly.
– mao
Nov 13 at 19:32
Possible duplicate of DB2 in Docker results in DB21018E
– bhamby
Nov 14 at 23:00
@mao when you say "dot in the db2profile" do you mean source it?
– JuanD
Nov 15 at 13:09
If the login shell for the userid is either bash or ksh/ksh93 thendot in
means the equivalent ofsource
in csh. A default installation of the current V11.1.3.3b runtime client on linux with bash as the configured shell will automatically update the .bashrc with the relevant dot in command for the db2profile.
– mao
Nov 15 at 13:24
@bhamby I dont think this is exactly the same as DB2 in Docker results in DB21018E as they seem to be spinning up a db in their container and need to keep it running as a service. Whereas Im trying to use this container to execute some db2 client commands against an external DB.
– JuanD
Nov 15 at 13:24
|
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
We have the need to create a docker container that also has the db2 client installed. This container will also have some shell scripts that make use of the db2 client.
We take a base Cent OS image and then add db2 via a RUN command:
COPY db2rtcl_nr.rsp /db2install/
RUN cd /db2install && curl -o ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz http://public_file_server.com/downloads/appTools/installs/db2/ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
tar -xvf ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rm -f ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rtcl/db2setup -u db2rtcl_nr.rsp -f sysreq &&
chown -R 1000:1000 /opt/ibm/db2/V11.1
ENV PATH="$PATH:/opt/ibm/db2/V11.1/bin"
The image builds ok with no errors.
However, when I try running and connecting to the container via interactive shell command:
docker run -it --entrypoint=/bin/bash db2Container
and try to invoke the db2 CLI with
db2
I get the error:
DB21018E A system error occurred. The command line processor could not
continue processing.
Whats confusing is that if I immediately run a bash
shell and then invoke the db2
CLI, it works:
bash
db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 11.1.0
You can issue database manager commands and SQL statements from the command
prompt. For example:
db2 => connect to sample
db2 => bind sample.bnd
For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
? CATALOG DATABASE for help on the CATALOG DATABASE command
? CATALOG for help on all of the CATALOG commands.
To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.
For more detailed help, refer to the Online Reference Manual.
db2 =>
Things I have tried to diagnose the issue:
When I 1st drop into the interactive shell session, I type
env > /tmp/env1.txt
I then typebash
and run
env > /tmp/env2.txt
When Idiff
the files, they are virtually identical EXCEPT for the variable:
SHLVL=2
which I know is just indicating that the 2nd shell is a nested shellWhen I 1st drop into the interactive shell session, I type
set > /tmp/set1.txt
I then typebash
and run
set > /tmp/set2.txt
When Idiff
the files, they are virtually identical EXCEPT for theSHLVL
variable again
Why is the db2 CLI accessible after I bash
in the container but not in the initial session when i have used docker run -it
?
We are attempting to use this container as an executable container that has the db2 client in it to connect to external DB2 databases. We are NOT trying to run a db2 DB in a container.
What I am starting to find is that I might have an issue with how the entrypoint is defined in our Dockerfile.
Using:
ENTRYPOINT cat /dev/null && /usr/bin/bash
the DB2 client is available when I run docker run -it ContainerName
without having to immediately type bash
BUT it does not work when I try to run the container as an executable docker run ContainerName
The closest I have come to the solution is this modification to the Dockerfile:
ENTRYPOINT
CMD ["/bin/bash"]
When I run the container as an executable docker run ContainerName db2 list command options
it works however NOW if I docker run -it ContainerName
I dont immediately have db2
commands available without typing bash
once. This is still problematic since this container will have shell script in it that need to be able to run db2 commands
docker db2
We have the need to create a docker container that also has the db2 client installed. This container will also have some shell scripts that make use of the db2 client.
We take a base Cent OS image and then add db2 via a RUN command:
COPY db2rtcl_nr.rsp /db2install/
RUN cd /db2install && curl -o ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz http://public_file_server.com/downloads/appTools/installs/db2/ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
tar -xvf ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rm -f ibm_data_server_runtime_client_linuxx64_v11.1.tar.gz &&
rtcl/db2setup -u db2rtcl_nr.rsp -f sysreq &&
chown -R 1000:1000 /opt/ibm/db2/V11.1
ENV PATH="$PATH:/opt/ibm/db2/V11.1/bin"
The image builds ok with no errors.
However, when I try running and connecting to the container via interactive shell command:
docker run -it --entrypoint=/bin/bash db2Container
and try to invoke the db2 CLI with
db2
I get the error:
DB21018E A system error occurred. The command line processor could not
continue processing.
Whats confusing is that if I immediately run a bash
shell and then invoke the db2
CLI, it works:
bash
db2
(c) Copyright IBM Corporation 1993,2007
Command Line Processor for DB2 Client 11.1.0
You can issue database manager commands and SQL statements from the command
prompt. For example:
db2 => connect to sample
db2 => bind sample.bnd
For general help, type: ?.
For command help, type: ? command, where command can be
the first few keywords of a database manager command. For example:
? CATALOG DATABASE for help on the CATALOG DATABASE command
? CATALOG for help on all of the CATALOG commands.
To exit db2 interactive mode, type QUIT at the command prompt. Outside
interactive mode, all commands must be prefixed with 'db2'.
To list the current command option settings, type LIST COMMAND OPTIONS.
For more detailed help, refer to the Online Reference Manual.
db2 =>
Things I have tried to diagnose the issue:
When I 1st drop into the interactive shell session, I type
env > /tmp/env1.txt
I then typebash
and run
env > /tmp/env2.txt
When Idiff
the files, they are virtually identical EXCEPT for the variable:
SHLVL=2
which I know is just indicating that the 2nd shell is a nested shellWhen I 1st drop into the interactive shell session, I type
set > /tmp/set1.txt
I then typebash
and run
set > /tmp/set2.txt
When Idiff
the files, they are virtually identical EXCEPT for theSHLVL
variable again
Why is the db2 CLI accessible after I bash
in the container but not in the initial session when i have used docker run -it
?
We are attempting to use this container as an executable container that has the db2 client in it to connect to external DB2 databases. We are NOT trying to run a db2 DB in a container.
What I am starting to find is that I might have an issue with how the entrypoint is defined in our Dockerfile.
Using:
ENTRYPOINT cat /dev/null && /usr/bin/bash
the DB2 client is available when I run docker run -it ContainerName
without having to immediately type bash
BUT it does not work when I try to run the container as an executable docker run ContainerName
The closest I have come to the solution is this modification to the Dockerfile:
ENTRYPOINT
CMD ["/bin/bash"]
When I run the container as an executable docker run ContainerName db2 list command options
it works however NOW if I docker run -it ContainerName
I dont immediately have db2
commands available without typing bash
once. This is still problematic since this container will have shell script in it that need to be able to run db2 commands
docker db2
docker db2
edited Nov 15 at 14:56
asked Nov 13 at 15:11
JuanD
3928
3928
Does it make a difference if you explicitly dot in the db2profile before you run the CLP? If it does, either the wrong startup profile is running, or that startup profile has'nt been properly updated, or is not running correctly.
– mao
Nov 13 at 19:32
Possible duplicate of DB2 in Docker results in DB21018E
– bhamby
Nov 14 at 23:00
@mao when you say "dot in the db2profile" do you mean source it?
– JuanD
Nov 15 at 13:09
If the login shell for the userid is either bash or ksh/ksh93 thendot in
means the equivalent ofsource
in csh. A default installation of the current V11.1.3.3b runtime client on linux with bash as the configured shell will automatically update the .bashrc with the relevant dot in command for the db2profile.
– mao
Nov 15 at 13:24
@bhamby I dont think this is exactly the same as DB2 in Docker results in DB21018E as they seem to be spinning up a db in their container and need to keep it running as a service. Whereas Im trying to use this container to execute some db2 client commands against an external DB.
– JuanD
Nov 15 at 13:24
|
show 1 more comment
Does it make a difference if you explicitly dot in the db2profile before you run the CLP? If it does, either the wrong startup profile is running, or that startup profile has'nt been properly updated, or is not running correctly.
– mao
Nov 13 at 19:32
Possible duplicate of DB2 in Docker results in DB21018E
– bhamby
Nov 14 at 23:00
@mao when you say "dot in the db2profile" do you mean source it?
– JuanD
Nov 15 at 13:09
If the login shell for the userid is either bash or ksh/ksh93 thendot in
means the equivalent ofsource
in csh. A default installation of the current V11.1.3.3b runtime client on linux with bash as the configured shell will automatically update the .bashrc with the relevant dot in command for the db2profile.
– mao
Nov 15 at 13:24
@bhamby I dont think this is exactly the same as DB2 in Docker results in DB21018E as they seem to be spinning up a db in their container and need to keep it running as a service. Whereas Im trying to use this container to execute some db2 client commands against an external DB.
– JuanD
Nov 15 at 13:24
Does it make a difference if you explicitly dot in the db2profile before you run the CLP? If it does, either the wrong startup profile is running, or that startup profile has'nt been properly updated, or is not running correctly.
– mao
Nov 13 at 19:32
Does it make a difference if you explicitly dot in the db2profile before you run the CLP? If it does, either the wrong startup profile is running, or that startup profile has'nt been properly updated, or is not running correctly.
– mao
Nov 13 at 19:32
Possible duplicate of DB2 in Docker results in DB21018E
– bhamby
Nov 14 at 23:00
Possible duplicate of DB2 in Docker results in DB21018E
– bhamby
Nov 14 at 23:00
@mao when you say "dot in the db2profile" do you mean source it?
– JuanD
Nov 15 at 13:09
@mao when you say "dot in the db2profile" do you mean source it?
– JuanD
Nov 15 at 13:09
If the login shell for the userid is either bash or ksh/ksh93 then
dot in
means the equivalent of source
in csh. A default installation of the current V11.1.3.3b runtime client on linux with bash as the configured shell will automatically update the .bashrc with the relevant dot in command for the db2profile.– mao
Nov 15 at 13:24
If the login shell for the userid is either bash or ksh/ksh93 then
dot in
means the equivalent of source
in csh. A default installation of the current V11.1.3.3b runtime client on linux with bash as the configured shell will automatically update the .bashrc with the relevant dot in command for the db2profile.– mao
Nov 15 at 13:24
@bhamby I dont think this is exactly the same as DB2 in Docker results in DB21018E as they seem to be spinning up a db in their container and need to keep it running as a service. Whereas Im trying to use this container to execute some db2 client commands against an external DB.
– JuanD
Nov 15 at 13:24
@bhamby I dont think this is exactly the same as DB2 in Docker results in DB21018E as they seem to be spinning up a db in their container and need to keep it running as a service. Whereas Im trying to use this container to execute some db2 client commands against an external DB.
– JuanD
Nov 15 at 13:24
|
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
0
down vote
After some more googling, I found this article: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
Using their Github page example, I updated our Dockerfile with:
RUN wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_amd64
RUN chmod +x /usr/local/bin/dumb-init
and also updated our Dockerfile's entrypoint with:
ENTRYPOINT ["/usr/local/bin/dumb-init", "--"]
CMD ["/bin/bash"]
The result has been that my dummy shell script (that has a db2 command in it) that lives inside of the container works when the docker container is called as an executable:
docker run myContainer /scripts/dummyDB2connect.sh
AND I can also interactively spin up and connect to the container to run db2 commands without having to type the extra bash
command.
Additional implementation of using an init tool to run as your initial entrypoint: github.com/krallin/tini
– JuanD
Nov 15 at 16:28
OR this all could have been solved had I started the container with--init
But for the sake of not having to remember to always type that we're gonna leave the dumb init in the ENTRYPOINT
– JuanD
Nov 15 at 16:54
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
After some more googling, I found this article: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
Using their Github page example, I updated our Dockerfile with:
RUN wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_amd64
RUN chmod +x /usr/local/bin/dumb-init
and also updated our Dockerfile's entrypoint with:
ENTRYPOINT ["/usr/local/bin/dumb-init", "--"]
CMD ["/bin/bash"]
The result has been that my dummy shell script (that has a db2 command in it) that lives inside of the container works when the docker container is called as an executable:
docker run myContainer /scripts/dummyDB2connect.sh
AND I can also interactively spin up and connect to the container to run db2 commands without having to type the extra bash
command.
Additional implementation of using an init tool to run as your initial entrypoint: github.com/krallin/tini
– JuanD
Nov 15 at 16:28
OR this all could have been solved had I started the container with--init
But for the sake of not having to remember to always type that we're gonna leave the dumb init in the ENTRYPOINT
– JuanD
Nov 15 at 16:54
add a comment |
up vote
0
down vote
After some more googling, I found this article: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
Using their Github page example, I updated our Dockerfile with:
RUN wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_amd64
RUN chmod +x /usr/local/bin/dumb-init
and also updated our Dockerfile's entrypoint with:
ENTRYPOINT ["/usr/local/bin/dumb-init", "--"]
CMD ["/bin/bash"]
The result has been that my dummy shell script (that has a db2 command in it) that lives inside of the container works when the docker container is called as an executable:
docker run myContainer /scripts/dummyDB2connect.sh
AND I can also interactively spin up and connect to the container to run db2 commands without having to type the extra bash
command.
Additional implementation of using an init tool to run as your initial entrypoint: github.com/krallin/tini
– JuanD
Nov 15 at 16:28
OR this all could have been solved had I started the container with--init
But for the sake of not having to remember to always type that we're gonna leave the dumb init in the ENTRYPOINT
– JuanD
Nov 15 at 16:54
add a comment |
up vote
0
down vote
up vote
0
down vote
After some more googling, I found this article: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
Using their Github page example, I updated our Dockerfile with:
RUN wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_amd64
RUN chmod +x /usr/local/bin/dumb-init
and also updated our Dockerfile's entrypoint with:
ENTRYPOINT ["/usr/local/bin/dumb-init", "--"]
CMD ["/bin/bash"]
The result has been that my dummy shell script (that has a db2 command in it) that lives inside of the container works when the docker container is called as an executable:
docker run myContainer /scripts/dummyDB2connect.sh
AND I can also interactively spin up and connect to the container to run db2 commands without having to type the extra bash
command.
After some more googling, I found this article: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
Using their Github page example, I updated our Dockerfile with:
RUN wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.2/dumb-init_1.2.2_amd64
RUN chmod +x /usr/local/bin/dumb-init
and also updated our Dockerfile's entrypoint with:
ENTRYPOINT ["/usr/local/bin/dumb-init", "--"]
CMD ["/bin/bash"]
The result has been that my dummy shell script (that has a db2 command in it) that lives inside of the container works when the docker container is called as an executable:
docker run myContainer /scripts/dummyDB2connect.sh
AND I can also interactively spin up and connect to the container to run db2 commands without having to type the extra bash
command.
answered Nov 15 at 14:55
JuanD
3928
3928
Additional implementation of using an init tool to run as your initial entrypoint: github.com/krallin/tini
– JuanD
Nov 15 at 16:28
OR this all could have been solved had I started the container with--init
But for the sake of not having to remember to always type that we're gonna leave the dumb init in the ENTRYPOINT
– JuanD
Nov 15 at 16:54
add a comment |
Additional implementation of using an init tool to run as your initial entrypoint: github.com/krallin/tini
– JuanD
Nov 15 at 16:28
OR this all could have been solved had I started the container with--init
But for the sake of not having to remember to always type that we're gonna leave the dumb init in the ENTRYPOINT
– JuanD
Nov 15 at 16:54
Additional implementation of using an init tool to run as your initial entrypoint: github.com/krallin/tini
– JuanD
Nov 15 at 16:28
Additional implementation of using an init tool to run as your initial entrypoint: github.com/krallin/tini
– JuanD
Nov 15 at 16:28
OR this all could have been solved had I started the container with
--init
But for the sake of not having to remember to always type that we're gonna leave the dumb init in the ENTRYPOINT– JuanD
Nov 15 at 16:54
OR this all could have been solved had I started the container with
--init
But for the sake of not having to remember to always type that we're gonna leave the dumb init in the ENTRYPOINT– JuanD
Nov 15 at 16:54
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53284001%2fdb2-client-in-docker%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Does it make a difference if you explicitly dot in the db2profile before you run the CLP? If it does, either the wrong startup profile is running, or that startup profile has'nt been properly updated, or is not running correctly.
– mao
Nov 13 at 19:32
Possible duplicate of DB2 in Docker results in DB21018E
– bhamby
Nov 14 at 23:00
@mao when you say "dot in the db2profile" do you mean source it?
– JuanD
Nov 15 at 13:09
If the login shell for the userid is either bash or ksh/ksh93 then
dot in
means the equivalent ofsource
in csh. A default installation of the current V11.1.3.3b runtime client on linux with bash as the configured shell will automatically update the .bashrc with the relevant dot in command for the db2profile.– mao
Nov 15 at 13:24
@bhamby I dont think this is exactly the same as DB2 in Docker results in DB21018E as they seem to be spinning up a db in their container and need to keep it running as a service. Whereas Im trying to use this container to execute some db2 client commands against an external DB.
– JuanD
Nov 15 at 13:24