I’ve recently spun up a Docker container running CentOS Linux version 7. In my office, we have a proxy server, so once the container was up, I consoled in and set the proxy manually:
[me#8adfa83bb9e2 /home/me]#
[me#8adfa83bb9e2 /home/me]# export http_proxy="http://10.10.10.101:8888"
[me#8adfa83bb9e2 /home/me]#
On a separate SO post, I learned about setting the proxy in the /etc/yum.conf file. So I added the following line to my /etc/yum.conf file:
proxy=http://10.10.10.101:8888
And then I did a “yum clean metadata”:
[me#8adfa83bb9e2 /home/me]# yum clean metadata
Loaded plugins: fastestmirror, ovl
Cleaning repos: base extras updates
0 metadata files removed
0 sqlite files removed
0 metadata files removed
[me#8adfa83bb9e2 /home/me]#
At this point, I figured I was home free. I did a “yum update”:
[me#8adfa83bb9e2 /home/me]#
[me#8adfa83bb9e2 /home/me]# yum update
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container error was
14: HTTP Error 403 – Forbidden
...and then a lot more stuff here...
Hmm. “HTTP Error 403”. That’s a new one for me; I’m used to running “yum update” and it just automagically works.
This isn’t a DNS problem; the Docker container can resolve and ping mirrorlist.centos.org. I tried to use wget to pull down that URL, but the container doesn’t have wget installed. When I try the same thing from the host machine:
me#hostmachine:/home/me$
me#hostmachine:/home/me$
me#hostmachine:/home/me$ sudo wget http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container
[1] 7039
[2] 7040
[3] 7041
[2] Done arch=x86_64
me#hostmachine:/home/me$
Redirecting output to ‘wget-log’.
[1]- Exit 8 sudo wget http://mirrorlist.centos.org/?release=7
[3]+ Done repo=os
me#hostmachine:/home/me$
me#hostmachine:/home/me$
me#hostmachine:/home/me$ ls -l
total 4
-rw-r--r-- 1 root root 382 Jan 21 19:55 wget-log
me#hostmachine:/home/me$
me#hostmachine:/home/me$
me#hostmachine:/home/me$ more wget-log
--2021-01-21 19:55:31-- http://mirrorlist.centos.org/?release=7
Resolving mirrorlist.centos.org (mirrorlist.centos.org)... 147.75.69.225, 18.225.36.18, 67.219.148.138, ...
Connecting to mirrorlist.centos.org (mirrorlist.centos.org)|147.75.69.225|:80... connected.
HTTP request sent, awaiting response... 503 Service Unavailable
2021-01-21 19:55:31 ERROR 503: Service Unavailable.
me#hostmachine:/home/me$
me#hostmachine:/home/me$
(Yes, the host machine has the correct proxy settings. It is not a Centos machine.)
Soooooooo… It looks like the yum service is “unavailable” from my host system. But I’ve run “yum update” on many, many other Centos machines in my environment. No idea what might be different here. Has anyone seen this before? Thank you.
FYI for anyone who may be looking at this post... The issue was a proxy server problem. Once I set the proxy server settings on both the host and container, the issue went away. I think in the above post, I'd set the proxy on the container, but not the host, and the host was NAT'ing the container's IP address when doing a "yum update."
I am trying to run solr on my machine. I have made everthing available for the same.
For example java and ruby versions are same as asked in the tutorials around.
This is how I am doing it.
solr_wrapper -d solr/config/ --collection_name hydra-development --version 6.3.0
This throws the followign error.
`exec': Failed to execute solr start: (RuntimeError)
Port 8983 is already being used by another process (pid: 1814)
Please choose a different port using the -p option.
The error message clearly indicates that some other process is using port 8983.
U need to find which process and try killing it
first run
$ lsof -i :8983
This will list applications running on port 8983. Lets say the pid of the process is 1814
run
$ sudo kill 1814
if you run into Error CREATEing SolrCore, it is mostly because of the permission issues caused by root installation
first cleanup the broken core:
bin/solr delete -c mycore
and recreate core as the solr user
su -u solr -c "/opt/solr/bin/solr create_core -c mycore"
I am attempting to create a docker machine on Digital Ocean, but with the 16.04 LTS instead of the default 15.10. The do-access-token file contains my token.
Here's the script (create-do):
#!/usr/bin/env bash
# Creates a digital-ocean server with Ubuntu 16.04 instead of the default
if [ "$1" != "" ]; then
echo "Creating: " $1
docker-machine \
create \
--driver digitalocean \
--digitalocean-access-token=`cat do-access-token` \
--digitalocean-image=ubuntu-16-04-x64 \
--digitalocean-ipv6=true \
$1
else
echo "Must have server name!"
fi
When I run the script like this:
$ ./create-do ps-server
It successfully allocates the machine at Digital Ocean, then craps out with this:
Creating: ps-server
Running pre-create checks...
Creating machine...
(ps-server) Creating SSH key...
(ps-server) Creating Digital Ocean droplet...
(ps-server) Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(systemd)...
Error creating machine: Error running provisioning: Something went wrong
running an SSH command!
command : sudo apt-get update
err : exit status 100
output : Reading package lists...
E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/lib/apt/lists/
The machine is running, but I can't get to it since the SSH key was apparently not set before things started going wrong.
Anyone seen this before and/or have a work-around?
Update: May 21, 2016
Broken again with same error this morning. Tried 4 times, failed same way each time.
Update: May 20, 2016
This was, according do Digital Ocean's support, due to an issue with their Ubuntu 16.04 image which has now been corrected and I have confirmed that this now works.
Related GitHub issue (not yet closed):
https://github.com/docker/machine/issues/3358
this worked for me:
docker-machine provision your-node
I've taken this solution from here: https://github.com/docker/machine/issues/3358
I hope this helps!
I have configure and installed couchdb 1.6.1 on ubuntu 10.04. While configuring and installing it said successfully done. But when I start couchdb it gives me error.
When start first..
Apache CouchDB 1.6.1 (LogLevel=info) is starting.
Apache CouchDB has started. Time to relax.
**[info] [<0.32.0>] Apache CouchDB has started on http://127.0.0.1:5984/**
When starting again
Apache CouchDB 1.6.1 (LogLevel=info) is starting.
**Failure to start Mochiweb: eaddrinuse**
[error] [<0.127.0>] {error_report,<0.31.0>,
{<0.127.0>,crash_report,[[{initial_call,
{mochiweb_socket_server,init,['Argument__1']}},
{pid,<0.127.0>},
{registered_name,[]},
{error_info,
{exit,eaddrinuse,
[{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_secondary_services,couch_server_sup,
<0.32.0>]},
{messages,[]},
{links,[<0.95.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,987},
{stack_size,24},
{reductions,467}],
[]]}}
{"init terminating in do_boot",{{badmatch,{error,{bad_return,{{couch_app,start,[normal,["/usr/local/etc/couchdb/default.ini","/usr/local/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1},{application_master,start_it_old,4}]}}}}}},[{couch,start,0},{init,start_it,1},{init,start_em,1}]}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
in local.ini I changed
Port to 5983 and also ip to 0.0.0.0 from 127.0.0.1
Nothing helped
When i run sudo netstat -tulpn
I get following output
tcp 0 0 127.0.0.1:5984 0.0.0.0:* LISTEN 21688/beam.smp
couchdb -s says Apache CouchDB is not running.
Thanks in advance
If you came here because you recently upgrade you CouchDB 2.0, make sure you updated your local.ini config file. The section for the web server configuration has changed (the name changed from something like httpd to chttpd). Because of that the port directive wasn't being picked up and it was defaulting to 80 which was the same as the web server.
Based on the error message entries provided, CouchDB is already up & running on your machine/ server with port 5984
**Failure to start Mochiweb: eaddrinuse**
That's why When you run sudo netstat -tulpn command on Linux based machine, you are getting the following output :
tcp 0 0 127.0.0.1:5984 0.0.0.0:* LISTEN 21688/beam.smp
Solutions :
couchdb is not a service script in the way you're trying to use it. It is just trying to start up again and failing because one is already running (erlang beam.smp process is still running).
Check & kill all CouchDB processes using following commands :
/bin/ps aux | grep couchdb | grep -v grep | awk '{print $2}' | xargs killl
Start CouchDB again using following command using root linux user :
service couchdb start
Note :
When you enter couchdb -s command, You are getting the message like Apache CouchDB is not running.
When you enter couchdb -d command, You are getting the message like Apache CouchDB is not running.
Reason for above outputs, You are executing above mentioned commands as non privileged linux users accounts.
Try to execute above mentioned commands as root Or couchDB running linux users accounts.
Even i faced same problem. I just did..
sudo apt-get update
sudo apt-get install couchdb
Note:i just re-installed couchdb now it's working fine. before re-install i did below configuration.
Install ICU and use locate to find the icu-config command:
locate icu-config
sudo apt-get install libicu-dev
for more details refer below link
https://wiki.apache.org/couchdb/Error_messages
I face the same problem...
Luckily there's a fix in the Couchdb Error messages documentation.
https://wiki.apache.org/couchdb/Error_messages
Problem
$ couchdb
Apache CouchDB 0.9.0a747640 (LogLevel=info) is starting.
Failure to start Mochiweb: eaddrinuse
{"init terminating in do_boot",{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1},{erl_eval,do_apply,5},{erl_eval,exprs,5},{init,start_it,1},{init,start_em,1}]}}
Solution
Edit your /etc/couchdb/couch.ini file and change the Port setting to an available port.
But mine didn't have couch.ini but had default.ini.
I changed that to another port that i guessed should be free and it worked
I have encountered this error in starting couchdb on ubuntu 16.04
The reason being erlang running on the port 5984, you would be something like below when running the command "netstat -tulpn"
0 0 127.0.0.1:5984 0.0.0.0:* LISTEN 13967/beam.smp
open the file /etc/couchdb/default.ini in super user mode and change the httpd port to some other port which is available and you would be able to start couchdb without any fail.
I'm trying to get my head around something that's been working on a Centos+Vagrant, but not on our providers RHEL (Red Hat Enterprise Linux Server release 6.5 (Santiago)). A sudo service docker restart hands this:
Stopping docker: [ OK ]
Starting cgconfig service: Error: cannot mount cpuset to /cgroup/cpuset: Device or resource busy
/sbin/cgconfigparser; error loading /etc/cgconfig.conf: Cgroup mounting failed
Failed to parse /etc/cgconfig.conf [FAILED]
Starting docker: [ OK ]
The service starts okey enough, but images cannot run. A mounting failed error is shown when I try. And the startup-log also gives a warning or two. Regarding the kernelwarning, centos gives the same and has no problems as Epel should resolve this:
WARNING: You are running linux kernel version 2.6.32-431.17.1.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0.
2014/08/07 08:58:29 docker daemon: 1.1.2 d84a070; execdriver: native; graphdriver:
[1233d0af] +job serveapi(unix:///var/run/docker.sock)
[1233d0af] +job initserver()
[1233d0af.initserver()] Creating server
2014/08/07 08:58:29 Listening for HTTP on unix (/var/run/docker.sock)
[1233d0af] +job init_networkdriver()
[1233d0af] -job init_networkdriver() = OK (0)
2014/08/07 08:58:29 WARNING: mountpoint not found
Anyone had any success overcoming this problem or should I throw in the towel and wait for the provider to update to RHEL 7?
I have the same issue.
(1) check cgconfig status
# /etc/init.d/cgconfig status
if it stopped, restart it
# /etc/init.d/cgconfig restart
check cgconfig is running
(2) check cgconfig is on
# chkconfig --list cgconfig
cgconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off
if cgconfig is off, turn it on
(3) if still does not work, may be some cgroups modules is missing. In the kernel .config file, make menuconfig, add those modules into kernel and recompile and reboot
after that, it should be OK
I ended up asking the same question at Google Groups and in the end finding a solution with some help. What worked for me was this:
umount cgroup
sudo service cgconfig start
The project of making Docker work was put on halt all the same. Later a problem of network connection for the containers. This took to much time to solve and had to give up.
So I spent the whole day trying to rig docker to work on my vps. I was running into this same error. Basically what it came down to was the fact that OpenVZ didn't support docker containers up until a couple months ago. Specifically this RHEL update:
https://openvz.org/Download/kernel/rhel6/042stab105.14
Assuming this is your problem, or some variation of it, the burden of solving it is on your host. They will need to follow these steps:
https://openvz.org/Docker_inside_CT
In my case
/etc/rc.d/rc.cgconfig start
was generating
Starting cgconfig service: Error: cannot mount cpu,cpuacct,memory to
/cgroup/cpu_and_mem: Device or resource busy /usr/sbin/cgconfigparser;
error loading /etc/cgconfig.conf: Cgroup mounting failed Failed to
parse /etc/cgconfig.conf
i had to use:
/etc/rc.d/rc.cgconfig restart
and it automagicly umouted and mounted groups
Stopping cgconfig service: Starting cgconfig service:
it seems like the cgconfig service not running,so check it!
# /etc/init.d/cgconfig status
# mkdir -p /cgroup/cpuacct /cgroup/memory /cgroup/devices /cgroup/freezer net_cls /cgroup/blkio
# cat /etc/cgconfig.conf |tail|grep "="|awk '{print "mount -t cgroup -o",$1,$1,$NF}'>cgroup_mount.sh
# sh ./cgroup_mount.sh
# /etc/init.d/cgconfig restart
# /etc/init.d/docker restart
This situation occurs when the kernel is booted with cgroup_disable=memory and /etc/cgconfig.conf contains memory = /cgroup/memory;
This causes only /cgroup/cpuset to be mounted instead of the full set.
Solution: either remove cgroup_disable=memory from your kernel boot options or comment out memory = /cgroup/memory; from cgconfig.conf.
The cgconfig service startup uses mount and umount which requires an extra privilege bump from docker.
See the --privileged=true flag here for more info.
I was able to overcome this issue by starting my container with:
docker run -it --privileged=true my-image.
Tested in Centos6, Centos6.5.