Container error when creating channel during running fabcar (fabric-sample) - hyperledger-fabric

Getting up to speed with Hyperledger and trying to run through the Hyperledger-Fabric tutorial fabcar, but hitting an error every time that I try to create the channel in the startFabric.sh script.
Here's the error:
Error response from daemon: Container 3640f4fca98aef120a2069292a3fc613954a0fbe7c625a31c2843ec643462 is not running
Ran all the pre-requisites and the commands listed, cloned the latest fabric-samples, updated node, tried longer start times. But still have this error. If anyone knows where I am going wrong would really appreciate some help to resolve. Thanks in advance.
Perhaps worth mentioning that I am running on Windows 7 and using Docker Toolbox.
startFabric.sh output is shown below.
$ ./startFabric.sh node
# don't rewrite paths for Windows Git Bash users
export MSYS_NO_PATHCONV=1
docker-compose -f docker-compose.yml down
Stopping ca.example.com ... done
Stopping couchdb ... done
Removing peer0.org1.example.com ... done
Removing orderer.example.com ... done
Removing ca.example.com ... done
Removing couchdb ... done
Removing network net_basic
docker-compose -f docker-compose.yml up -d ca.example.com orderer.example.com peer0.org1.example.com couchdb
Creating network "net_basic" with the default driver
Creating ca.example.com ... done
Creating couchdb ... done
Creating orderer.example.com ... done
Creating peer0.org1.example.com ... done
# wait for Hyperledger Fabric to start
# incase of errors when running later commands, issue export FABRIC_START_TIMEOUT=<larger number>
export FABRIC_START_TIMEOUT=10
#echo ${FABRIC_START_TIMEOUT}
sleep ${FABRIC_START_TIMEOUT}
# Create the channel
docker exec -e "CORE_PEER_LOCALMSPID=Org1MSP" -e "CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/msp/users/Admin#org1.example.com/msp" peer0.org1.example.com peer channel create -o orderer.example.com:7050 -c mychannel -f /etc/hyperledger/configtx/channel.tx
Error response from daemon: Container 4ebfce361f3e71dd2d678efca1dbf1853cc5387b491f706917b8c54013ec6a80 is not running
docker ps output:
$ docker ps
CONTAINER ID IMAGE COMMAND CRED STATUS PORTS AMES
2d93296f3cb1 hyperledger/fabric-couchdb "tini -- /docker-entâ¦" 13nutes ago Up 13 minutes 4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcpcouchdb
6b8638d0ecaf hyperledger/fabric-ca "sh -c 'fabric-ca-seâ¦" 13nutes ago Up 13 minutes 0.0.0.0:7054->7054/tcp ca.example.com
docker ps -a output:
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4ebfce361f3e hyperledger/fabric-peer "peer node start" 15 minutes ago Exited (1) 15 minutes ago peer0.org1.example.com
1187120cdcd0 hyperledger/fabric-orderer "orderer" 15 minutes ago Exited (1) 15 minutes ago orderer.example.com
2d93296f3cb1 hyperledger/fabric-couchdb "tini -- /docker-entâ¦" 15 minutes ago Up 15 minutes 4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp couchdb
6b8638d0ecaf hyperledger/fabric-ca "sh -c 'fabric-ca-seâ¦" 15 minutes ago Up 15 minutes 0.0.0.0:7054->7054/tcp ca.example.com

For me this issue was caused by the volume handoff from WSL (Windows Subsystem for Linux - available on Windows 10) to Docker. Use Kitematic to view your docker containers (See screenshot below and note how the folder path is messed up). Click the container and go to "Settings" and "Volumes". Changing the volume manually made it run properly.
In my case, docker automatically is changing \c to C:
I was able to resolve it with this trick: https://superuser.com/questions/1195215/docker-client-on-wsl-creates-volume-path-problems/1203233
WSL mounts the windows drives at /mnt/ (so /mnt/c/ = C:). If we create a /c/ bind point, this allows Docker to properly interpret this as C:\
Here's the process:
Bind the drive and download fabric to your windows user directory by using the following set of commands (one at a time)
sudo mkdir /c
sudo mount --bind /mnt/c /c
cd /c/Users/YOUR_WINDOWS_USERNAME #(go to C:\Users to see what its called)
mkdir blockchain #(or whatever you want to call it)
cd blockchain
curl -O https://raw.githubusercontent.com/hyperledger/composer-tools/master/packages/fabric-dev-servers/fabric-dev-servers.tar.gz
tar -xvf fabric-dev-servers.tar.gz
cd ~/fabric-dev-servers
export FABRIC_VERSION=hlfv12
./downloadFabric.sh
Now you should be able to successfully run Fabric
./startFabric.sh
It may ask you to share C drive with docker. You should do so. You can check the volume mount points and containers in Kitematic, like below

Try to do:
Remove all containers - docker rm -f $(docker ps -aq)
Remove network - docker network prune
Remove the chaincode image (if existing) - docker rmi dev-peer0.org1.example.com
Restart docker
Run startFabric.sh again.
Hope help you.

The actual problem is that the location /etc/hyperledger/msp/peer/signcerts is not accessible. For some reason it seems Docker Toolbox looks for this location under the home directory. So, check the home directory in the Docker VM using
echo $HOME (in my case it is C:/Users/knwny) and then place the fabric-samples folder in that location.
This fixed the problem for me.

Got this working by re-running through the fabric installation guidelines: http://hyperledger-fabric.readthedocs.io/en/latest/prereqs.html
The following procedure was entirely performed in a windows account with admin rights
Initial steps:
Set the GOPATH environment variable
Checked that Go is building executables correctly
All next steps in powershell in Admin mode
Ran npm install npm#5.6.0 -g
sudo apt-get install python (note that for me This command failed, but had python anyway and it seemed to work OK as it couldn't find sudo)
Checked that python 2.7 is installed correctly
Set git config --global core.autocrlf false
Set git config --global core.longpaths true
Ran npm install --global windows-build-tools
Ran npm install --global grpc
Ran the following in Git Bash because cURL didnt work in powershell:
curl -sSL http:/ /bit.ly/2ysbOFE | bash -s 1.2.0
Note that for the above command to work successfully I needed to have Docker running in a shell, i.e. running the Docker Toolbox installed start.sh script (I ran in Git Bash and worked OK).
Finally, in registerUser.js and enrollAdmin.js changed the local host, to be the IP address stated on docker on startup.
fabric_ca_client = new Fabric_CA_Client('http://localhost:7054', null , '', crypto_suite);
After doing this I re-ran the Fabric-samples 1) first-network and 2) fabcar examples and they worked as expected!! I think that I had missed out the GoPath and hadn't successfully installed the cURL command first time I tried.
Thanks to Nhat Duy and knwny for your help to resolve this issue.

Related

Can't run docker as a normal user

I can't run docker commands as my own user. But I know that the service is running because I can run commands as sudo:
$ docker ps
Cannot connect to the Docker daemon at unix:///run/user/1000/docker.sock. Is the docker daemon running?
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
(snip) (snip) (snip) 13 days ago Up 2 hours (healthy) 9000/tcp (snip)
I am successfully running a few containers, and they each work, but I have another not listed in 👆 that I need to run as my own user.
I am part of the docker group:
$ groups
docker www-data video tim
I'm not sure what else to check. I do have this:
$ echo $DOCKER_HOST
unix:///run/user/1000/docker.sock
Also:
$ uname -r
5.4.0-65-generic
$ docker --version
Docker version 19.03.6, build 369ce74a3c
This is on Ubuntu 18.04.5 LTS
As you followed all the post installation steps correctlly, as far as I can tell, my best guess is that has to do with the DOCKER_HOST environment variable.
Does it help if you unset DOCKER_HOST? (Perhaps you need to log out, so it has an effect.)
On my system, docker ps works with sudo, but once I set DOCKER_HOST=unix:///run/user/1000/docker.sock, I get the same error as you.
For some background, here is a question about the DOCKER_HOST variable. In essence, that variable should normally not be set.
Return to the default sock path (unix:///var/run/docker.sock), by unsetting DOCKER_HOST and removing an errant config files:
unset DOCKER_HOST
rm -r ~/.docker
The Docker Daemon must be restarted after creating the “docker” group:
sudo services docker restart
Then, ensure you add your current user to the group:
sudo usermod -a -G docker $USER
This will ensure your user has access to the socket file.
UPDATE: 12/2022
Recently had to do this on Ubuntu 22.04 LTS and ran into the login shell persisting the previous group.
Since the UI manages the login shell, a restart is either required, or you need to replace the process with exec. You can work around this issue, until you restart, by replacing your current shell process: (use $0 instead, if $SHELL doesn't match your preferred shell)
exec sudo -u $USER -E $SHELL

Docker service exits on deploy-over-SSH from Jenkins but manually succeeds

I have a strange issue. I have configured a SSH_USER on Jenkins and trying to deploy a simple docker-service with "deploy-over-SSH".
Every time I deploy it Exits as below, and logs just says "Terminated"
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bea48e1ee755 localhost/my-image:latest /bin/sh -c npm ru... 13 seconds ago Exited (143) 13 seconds ago 0.0.0.0:6007->3000/tcp my-cont
$ docker logs my-cont
Terminated
But if I try running manually on the same server with same SSH_USER, I am able to run docker container successfully.
docker run -d -it -p 6007:3000 --name my-cont my-image
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
nce48e1ee721 localhost/my-image:latest /bin/sh -c npm ru... 21 minutes ago 21 minutes ago 0.0.0.0:6007->3000/tcp my-cont
The script I am running over-SSH is very simple from Jenkins, I am passing the Port from Jenkins,
$ bash ./run.sh $Port
docker run -d -it -p $1:3000 --name my-cont my-image
Not sure , what is causing the issue.
As I mentioned in the comment, upgrading the version 'podman version 2.0.5' worked for me.
The error or docker logs never gave me any hint, clue on version.
But that was the solution. Thanks for your comments.

Old versions of chaincode being run unintentionally

Old chaincode is being run even after I do the following:
1. stop and remove all docker containers with
docker stop $(docker ps -aq) && docker rm $(docker ps -aq)
2. remove shared volume
sudo rm -r prod/
After restarting the network I then try to install chaincode with the same chaincodeID and same version number as old network. Somehow the old chaincode that was deployed on the previous network gets instantiated instead of the new one. There must be some cache somewhere that I am not clearing. These are the volumes set in my docker-compose.yaml Any help would be great. Thanks
- ../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp
- ../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls
- ../prod/peer0.org1.example.com:/var/hyperledger/production
You seem to have old images created for the chaincode not removed.
I personally run
docker rmi $(docker images |grep 'dev-peer')
to delete my dev peer imaegs which contain the chaincode before bringing up the network and when i dont want to change version of the chaincode. Try this out but it will remove EVERY image containing that dev-peer string! So when you have some images called the same way they are removed as well.

Dockerized nginx shuts down after a few seconds

I'm working with Ubuntu 18 and I´m trying to run a dockerized nginx with a shared file between the host machine and the container: /home/ric/wrkspc/djangodocker/djangodocker/nginx.conf
I do so by running the following command, after which I'm prompted with container's ID:
$ sudo docker container run -v /home/ric/wrkspc/djangodocker/djangodocker/nginx.conf:/etc/nginx/nginx.conf:ro -d nginx
facc4d32db31de85d6f360e581bc7d36f257ff66953814e985ce6bdf708c3ad0
Now, if I try to list all the running containers, the nginx one doesn't appear listed:
(env) ric#x:~/wrkspc/djangodocker/djangodocker$ sudo docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
36090ff0759c mysql "docker-entrypoint.s…" 3 days ago Up 3 days 0.0.0.0:3306->3306/tcp, 33060/tcp boring_panini
Sometimes, if I run the docker ls command fast enough, I can see the nginx container listed for just a few seconds and then it disappears.
Why is the nginx container not being listed?
I think container immediately exits after started.
can you troubleshoot by looking into docker logs using the command
docker logs containerID
Also, you can try running the container interactively to identify the error without using -d option

Docker command can't connect to Docker daemon

I want to make a move to Docker, so I've just started to mess around with it. I've installed Docker on a VirtualBox Ubuntu 15.10 (Wily Werewolf) installation and as suggested here I then tried running a basic nginx Docker image:
$ docker run --name mynginx1 -P -d nginx
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
So I checked out whether Docker was running:
$ sudo service docker status
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since vr 2015-11-06 08:41:48 CET; 15min ago
Docs: https://docs.docker.com
Main PID: 7542 (docker)
CGroup: /system.slice/docker.service
└─7542 /usr/bin/docker daemon -H fd://
nov 06 08:41:47 kramer65-VirtualBox systemd[1]: Starting Docker Application Container Engine...
nov 06 08:41:47 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:47.900410966+01:00" level=info msg="API ...ock"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.033514149+01:00" level=info msg="Fire...lse"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.141594321+01:00" level=info msg="Defa...ess"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.416294436+01:00" level=warning msg="Y...it."
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.565507576+01:00" level=info msg="Load...rt."
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.567907022+01:00" level=info msg="Load...ne."
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.567945214+01:00" level=info msg="Daem...ion"
nov 06 08:41:48 kramer65-VirtualBox docker[7542]: time="2015-11-06T08:41:48.567969891+01:00" level=info msg="Dock....9.0
nov 06 08:41:48 kramer65-VirtualBox systemd[1]: Started Docker Application Container Engine.
Hint: Some lines were ellipsized, use -l to show in full.
This suggests that the Docker daemon is actually already running, but to be sure I just started the Docker daemon manually:
$ sudo docker daemon
INFO[0000] API listen on /var/run/docker.sock
INFO[0000] [graphdriver] using prior storage driver "aufs"
INFO[0000] Firewalld running: false
INFO[0000] Default bridge (docker0) is assigned with an IP address XXX.XX.X.X/XX. Daemon option --bip can be used to set a preferred IP address
WARN[0000] Your kernel does not support swap memory limit.
INFO[0000] Loading containers: start.
INFO[0000] Loading containers: done.
INFO[0000] Daemon has completed initialization
INFO[0000] Docker daemon commit=76d6bc9 execdriver=native-0.2 graphdriver=aufs version=1.9.0
I then tried running the image again, but with the same result:
$ docker run --name mynginx1 -P -d nginx
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
I tried sudo'ing the command, but to no avail. What am I doing wrong here?
You need to add your current user to the docker group as follows:
sudo usermod -aG docker $(whoami)
then logout & login again into the system or restart the system.
test by docker version
for further info how to install docker-engine follow docker documentation
Add the user to the docker group
Add the docker group if it doesn't already exist:
sudo groupadd docker
Add the connected user "${USER}" to the docker group:
sudo gpasswd -a ${USER} docker
Restart the Docker daemon:
sudo service docker restart
Either do a newgrp docker or log out/in to activate the changes to
groups.
Usually, the following command does the trick:
sudo service docker restart
This, instead of docker start for the cases where Docker seems to already be running.
If that works then, as suggested and in another answer and on this GitHub issue, if you haven't added yourself in the docker group do it by running:
sudo usermod -aG docker <your-username>
And you're most likely good to go.
As for anybody else bumping into this, in some OS's docker doesn't start right after you install it and, as a result, the same can't connect to daemon message appears. In this case you can first verify that Docker is indeed not running by checking the status of your docker service by executing:
sudo service docker status
If the output looks something like: docker stop/waiting instead of docker start/running, process 15378 then it obviously means Docker is not active. In this case make sure you start it with:
sudo service docker start
And, as before, you'll most likely be good to go.
note to self: I get the error from the question's title when I forget to run docker command with sudo:
sudo docker run ...
[Ubuntu 15.10]
Had the same issue and what worked for me was:
Checking the ownership of /var/run/docker.sock
ls -l /var/run/docker.sock
If you're not the owner then change ownership with the command
sudo chown *your-username* /var/run/docker.sock
Then you can go ahead and try executing the docker commands hassle-free :D
After installing docker on Ubuntu, I ran the following command:
sudo service docker start
Have you tried it?
After install everything and start the service, try close your terminal and open it again, then try pull your image
Edit
I also had this issue again, if the solution above won't worked, try this solution that is the command bellow
sudo mv /var/lib/docker/network/files/ /tmp/dn-bak
Considerations
If command above works you probably are with network docker problems, anyway this resolves it, to confirm that, see the log with the command bellow
tail -5f /var/log/upstart/docker.log
If the output have something like that
FATA[0000] Error starting daemon: Error initializing network controller: could not delete the default bridge network: network bridge has active endpoints
/var/run/docker.sock is up
You really are with network problems, however I do not know yet if the next time you restart(update, 2 months no issue again) your OS will get this problem again and if it is a bug or installation problem
My docker version
Client:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:12:04 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:12:04 UTC 2015
OS/Arch: linux/amd64
I had the same problem. Been struggling for two days to solve it.
It only worked when I did:
According to Docker's Tutorial, you need to add the Docker key if not already added using:
$ sudo wget -qO- https://get.docker.com/gpg | sudo apt-key add -
Then make sure you grant docker privileges to yourself using:
$ sudo usermod -aG docker $USER
Hope this helps you too.
enter as root (sudo su) and try this:
unset DOCKER_HOST
docker run --name mynginx1 -P -d nginx
I've the same problem here, and the docker command only worked running as root, and also with this DOCKER_HOST empty
PS: also beware that the correct and official way to install on Ubuntu is to use their apt repositories (even on 15.10), not with that "wget" thing.
For OSX:
After opening docker and starting the 'default' machine via the Quickstart Terminal (https://docs.docker.com/engine/installation/mac/), you try docker commands and get this "can't connect to docker daemon" message, it turns out you need some env variables set:
eval "$(docker-machine env default)"
Then try it out with docker run hello-world to see if everything is peachy.
For the ones who already tried restarting your machine, unsetting the environment variable DOCKER_HOST as told in the docker env documentation and all the rest just try to go with the
sudo service docker restart
Only this did the trick for me even after restarting the machine.
Giving non-root access - from docker
Add the docker group if it doesn't already exist.
$ sudo groupadd docker
Add the connected user "${USER}" to the docker group.
Change the user name to match your preferred user.
You may have to logout and log back in again for
this to take effect.
$ sudo gpasswd -a ${USER} docker
Restart the Docker daemon.
$ sudo service docker restart
This question is currently number 3 on a Google search. After doing some research into solving this problem on my Linux system I thought I would write this answer. The original post states the problem is on Ubuntu but I also experienced the issue using Fedora. With that in mind, here is what I did to fix the problem.
On Fedora 22
Installing Docker:
$> curl -fsSL https://get.docker.com/ | sh
After installing Docker:
A user needs to be added to the docker group.
$> sudo usermod -aG docker
The docker daemon needs to be started
$> sudo service docker start
You can set the daemon to start at boot
$> sudo chkconfig docker on
You can verify the docker service is running
$> service docker status
And one last final check
$> docker run hello-world
Tested in Ubuntu 16.04
# Create the docker group and add your user to the docker group
groupadd docker
usermod -aG docker $USER
newgrp docker
# Configure docker service to be exposed
mkdir -p /etc/systemd/system/docker.service.d
echo -e '[Service]\nExecStart=\nExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2376' >> /etc/systemd/system/docker.service.d/override.conf
# restart service
systemctl daemon-reload
service docker restart
Try to use "sudo" with the command you are running.
I have same issue while running docker.
you can run commands as sudo user:
sudo docker ***your command here***
For Ubuntu:
Happened with me when I updated docker.
You need to unmask the service and socket and then restart the service.
Following worked for me:
systemctl unmask docker.service
systemctl unmask docker.socket
systemctl start docker.service
What happend behind the scenes
systemd also has the ability to mark a unit as completely unstartable, automatically or manually, by linking it to /dev/null. This is called masking the unit, and is possible with the mask command.
sudo systemctl mask docker.service
You can check the list of masked services using:
sudo systemctl list-unit-files
To enable auto/manual start of service you need to unmask it using:
sudo sytemctl unmask docker.service
Now the service will be enabled as shown below
As docker binds to a unix socket which is owned by root while starting up, using 'sudo' along with the docker commands will work.
I also had the same issue. The problem was in sockets allocated to docker-daemon and docker-client.
First, permission was not set for the docker-client on docker.sock You can set it using "sudo usermod -aG docker $USER"
Then check your bash file where the docker-client is running, For me it was on 0.0.0.0:2375, while docker-daemon was running on unix socket.(It was set in the configuration file of dockerd).
Just comment the bash-line and it'll work fine.
But if you want to make it work on TCP port instead of unix socket, change the configuration file of dockerd and set it on 0.0.0.0.2375 and keep the line in bash as it is if present or set it to 0.0.0.0:2375.
Perhaps this will help someone, as the error message is extremely unhelpful, and I had gone through all of the standard permission steps numerous times to no avail.
Docker occasionally leaves ghost environment variables in place that block access, despite your system otherwise being correctly set up. The following shell commands may make it accessible again, if you have had it running at one point and it just stopped cooperating after a reboot:
unset DOCKER_HOST
unset DOCKER_TLS_VERIFY
unset DOCKER_TLS_PATH
docker ps
I had a previously working docker install, and after rebooting my laptop it simply refused to work. Was correctly added to the docker user group, had the correct permissions on the socket, etc, but could still not run docker login, docker run ..., etc. This fixed it for me. Unfortunately I have to run this on each reboot. This is mentioned on a couple of github issues also as a workaround, although it seems like a bug that this is a persistent barrier to correct operation of Docker (note: I am on Arch Linux, not OSX, but this was the same issue for me).
I was able to fix that by running the following command:
sudo mv /var/lib/dpkg/info/docker-ce* /tmp
I have faced same error on Amazon EC2 instance. The issue got fixed after restarting the instance.
Add current user to docker group:
sudo usermod -aG docker $(whoami)
For Ubuntu 16.04
Inside file /lib/systemd/system/docker.service change:
ExecStart=/usr/bin/dockerd fd://
with:
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375
Inside file /etc/init.d/docker change:
DOCKER_OPTS=
with:
DOCKER_OPTS="-H tcp://0.0.0.0:2375"
and then restart your computer.

Resources