I am trying to create a docker image for Couchbase and i get the following error with the dockerfile on CentOS image.
# expose default port
EXPOSE 8091
ENV PATH $PATH:/opt/couchbase/bin
RUN cd /var/tmp &&\
wget http://packages.couchbase.com/releases/2.5.0/couchbase-server-enterprise_2.5.0_x86_64.rpm &&\
rpm -ivh couchbase-server-enterprise_2.5.0_x86_64.rpm &&\
chkconfig couchbase-server on &&\
service couchbase-server start
#add start script to the container
ADD start /start
#make the script executable
RUN chmod 0755 /start
EXPOSE 11211 11210 11209 4369 8092 18091 18092 11214 11215
#start mysql service and launch the command console
CMD ["/start"]
When building it, i am getting the following error ..
ulimit: open files: cannot modify limit: Operation not permitted
ulimit: max locked memory: cannot modify limit: Operation not permitted
I saw in a forum that we can set these values in docker.conf files. But i tried creating this file /etc/init/docker.conf and put the following lines in that file-
limit memlock unlimited unlimited
limit nofile 262144
but still i get the same error.
If i follow the same steps manually on CentOS VM, it works. So i guess i need to set something on Docker CentOS image.
Resolved the issue by setting the ulimit on the Docker host using the following command:
ulimit -l unlimited
ulimit -n 10240
ulimit -c unlimited
Then restart the Docker service on the CentOS. That fixed the issue since these values of the host will be inherited by the container.
Only root can increase the hard upper limit, and you have to be logged in as root, sudo won't work.
su root
ulimit -n 10240
Related
I recently installed memcached via the commands sudo apt-get install memcached and sudo apt-get install python-memcache.
I next did some quick settings in /etc/memcached.conf (attached at the end of the question). For the record, I'm connecting via unix socket. Next I tried sudo service memcached restart to get it up and running.
However, it didn't work. I then manually created a dir in /var/run called memcached and ran chown memcache:root /var/run/memcached.
Then doing sudo service memcached restart was a success.
However, if I do sudo reboot and log back into the machine after the reboot,the sock file (and the folder with it) are gone.
How do I get memcached to persist in this scenario? I'm on Ubuntu 14.04, and the memcached config file is as follows:
# memcached default config file
# 2003 - Jay Bonci <jaybonci#debian.org>
# This configuration file is read by the start-memcached script provided as
# part of the Debian GNU/Linux distribution.
# Run memcached as a daemon. This command is implied, and is not needed for the
# daemon to run. See the README.Debian that comes with this package for more
# information.
-d
# Log memcached's output to /var/log/memcached
logfile /var/log/memcached.log
# Be verbose
-v
# Be even more verbose (print client commands as well)
# -vv
# Start with a cap of 64 megs of memory. It's reasonable, and the daemon default
# Note that the daemon will grow to this size, but does not start out holding this much
# memory
#-m 64
-m 320
# Default connection port is 11211
#-p 11211
# Run the daemon as root. The start-memcached will default to running as root if no
# -u command is present in this config file
-u memcache
# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
#-l 127.0.0.1
-s /var/run/memcached/memcached.sock
-a 0777
# Limit the number of simultaneous incoming connections. The daemon default is 1024
# -c 1024
# Lock down all paged memory. Consult with the README and homepage before you do this
# -k
# Return error when memory is exhausted (rather than removing items)
# -M
# Maximize core file limit
# -r
Please ask for more information in case you need it.
I solved my problem by delving into memcached's init.d startup script.
I added the following lines at the head of the script (they weren't there already):
if [ ! -d /var/run/memcached ]; then
mkdir /var/run/memcached
chown memcache /var/run/memcached
fi
I saved, and then set it to start automatically on boot with:
sudo update-rc.d memcached defaults
sudo update-rc.d memcached enable
To test streaming replication, I would like to create a second Postgres instance on the same machine. The idea is that if it can be done on the test server, then it should be trivial to set it up on the two production servers.
The instances should use different configuration files and different data directories. I tried following the instructions here http://ubuntuforums.org/showthread.php?t=1431697 but I haven't figured out how to get Postgres to use a different configuration file. If I copy the init script, the scripts are just aliases to the same Postgres instance.
I'm using Postgres 9.3 and the Postgres help pages say to specify the configuration file on the postgres command line. I'm not really sure what this means. Am I supposed to install some client for this to work? Thanks.
I assume you can work your way out on using postgresql utilities.
Create the clusters
$ initdb -D /path/to/datadb1
$ initdb -D /path/to/datadb2
Run the instances
$ pg_ctl -D /path/to/datadb1 -o "-p 5433" -l /path/to/logdb1 start
$ pg_ctl -D /path/to/datadb2 -o "-p 5434" -l /path/to/logdb2 start
Test streaming
Now you have two instances running on ports 5433 and 5434. Configuration files for them are in data dirs specified by initdb. Tweak them for streaming replication.
Your default installation remains untouched in port 5432.
On Debian based distros you could use pg_createcluster instead of initdb:
$ pg_createcluster -u [user] -g [group] -d /path/to/data -l /path/to/log -p 5433
Also pg_ctlcluster is an alternative to pg_ctl.
Steps to create New Server Instance on PostgreSQL 9.5
On command prompt run:
initdb -D Instance_Directory_path -U username -W
(prompts for password)
Once the new Instance Directory is created. Run command prompt as Administrator
pg_ctl register -N service_name -D Instance_Directory_path -o "-p port_no"
After the service is registered, start server
pg_ctl start -D Instance_Directory_path -o "-p port_no"
To complete other answers, on CentOS 6 AND 7.
After running something like
$ initdb -D /path/to/newdb
You'll have to change at least port configuration option and, probably, listen_addresses in config file postgresql.conf.
Instead of starting inmediatly this new instance, which has been explained in previous answers, maybe you want new instance to run automatically on system start (in case of shutdown, e.g.). To do this, as CentOS doesn't have pg_ctl register option (only for Windows) you'll have to create a new service file and register it in order systemctl or service can start it up automatically.
Centos 6
Follow next commands to get service's init file:
[root#machine ~]# service postgresql-9.6 edit
Usage: /etc/init.d/postgresql-9.6 {start|stop|status|restart|upgrade|condrestart|try-restart|reload|force-reload|initdb|promote}
[root#machine ~]# cd /etc/init.d # Now we know where service file is
[root#machine init.d]# cp -p postgresql-9.6 postgresql-9.6_5433
[root#machine init.d]# vi postgresql-9.6_5433
Now you can change PGDATA directory with the one where new instance resides. If you're using Postgresql version previous to 9.4 (which you shouldn't by the time of this answer) you'll have to change PGPORT too with the value where new instance is listening to.
The name of the new service is up to you. I usually take original service name and add port number at the end.
Now you only have to register new service:
[root#machine init.d]# chkconfig postgresql-9.6_5433 on # service registered!
[root#machine init.d]# service postgresql-9.6_5433 start
Iniciando servicios postgresql-9.6_5433: [ OK ]
[root#machine init.d]# service postgresql-9.6_5433 status
Se está ejecutando postgresql-9.6_5433 (pid 120993)...
Centos 7
In CentOS 7 instead of service to control services running on the machine you have systemctl and commands and paths change a bit. But the process is the same: create new service file, edit with the new location/port, register and start:
[root#localhost ~]# locate postgresql.service
/etc/systemd/system/multi-user.target.wants/postgresql.service
/usr/lib/systemd/system/postgresql.service
[root#localhost ~]# cd /usr/lib/systemd/system
[root#localhost ~]# cp -p postgresql.service postgresql_5433.service
[root#localhost ~]# vi postgresql_5433.service
# Change PGDATA and maybe PGPORT if PG version <9.4
[root#localhost ~]# systemctl enable postgresql_5433.service
[root#localhost ~]# systemctl start postgresql_5433.service
[root#localhost ~]# systemctl list-unit-files | grep postgres
postgresql.service enabled
postgresql_5433.service enabled
I have postgres docker image, which can be deployed on Bluemix Containers. It works fine. But when I attached volume, container fails with permission error.
I am using $PGDATA as /var/lib/postgresql/data.
Entry point script, I have mentioned, sudo chown -R postgres /var/lib/postgresql/data. Also I have mounted volume using option -v data1:/var/lib/postgresql/data
But when I start container, chown always fails with 'Permission Error'.
I have added postgres user as part of root group.
But it still gives me same error.
chown: changing ownership of ?/var/lib/postgresql/data?: Permission denied
How do I fix this issue?
I found a way arround adding postgress to root group (which is a security flaw in my eyes).
At first you make the volume writable for everyone, then add an folder in the volume with the user you want to run your daemon with (in your case postgres). After this you can reset the volumes access right to default again.
I use this snippet in my entrypoint scripts on setup time:
chsh -s /bin/bash www-data
chmod 777 /var/www
su -c "mkdir -p /var/www/html" www-data
chmod 755 /var/www
usermod -s /bin/false www-data
Instead of chown volume directory to postgres user, change its permission to allow group write:
$ chmod g+w $PGDATA
Since you already added root group to user postgres it should work now.
I'm extremely new to using terminal commands. I'm trying to run an app locally on my Mac and i'm having difficulty with that so I'm trying to pick through the possible issues. The first one is the when using the mongod command I get an error of the flowing
/usr/local/bin/mongod:3: warning: Insecure world writable dir /usr/local in PATH, mode 040777
all output going to: /usr/local/var/log/mongodb/mongo.log
Does this seem to be a problem or erroneous?
Having /usr/local world writable is never a good idea. Normal permissions only allow the superuser (root) to write to these system directories.
To bring you back closer to the default run:
sudo chmod 755 /usr/local
Furthermore you might want to clear the world writable bit on every subdir and file by running:
sudo chmod -R o-w /usr/local
This will mean you have to either start mongod as root or change the database path to somewhere you can write (for example in your homedir).
I run mongod on my developer machine using the following command:
mongod --bind_ip 127.0.0.1 --dbpath ~/mongo -v --profile 2
This means the following:
--bind_ip 127.0.0.1 make sure others in your network can't access your database
--dbpath ~/mongo save database files in your home dir in the directory mongo
-v show queries that are being executed
--profile 2 shows performance and profile information on queries
You should run mongod -h to see all available options.
Am running MongoDB 2.2 on Ubuntu and if I run:
sudo mongod
I get an error that it can't find /data/db, which is not where the database is. In mongod.conf the database path is specified as the Ubuntu 10gen default /var/lib/mongodb which is where the db is located. Seems like mongod is not finding the conf file. So when I run:
sudo mongod -f /etc/mongodb.conf
The server starts up fine and output is logged to the log file: /var/log/mongodb/mongodb.log. All is happy. I can switch to another shell, log into mongo shell, see the databases and run queries.
So, I cancel out of that and try to run as a service:
> sudo status mongodb
mongodb stop/waiting
> sudo start mongodb
mongodb start/running, process 10468
Looks good so far, but the mongo server did not start. Running another:
> sudo status mongodb
mongodb stop/waiting
> mongo
MongoDB shell version: 2.2.0
connecting to: test
Sat Sep 1 19:07:43 Error: couldn't connect to server 127.0.0.1:27017 src/mongo/shell/mongo.js:91
exception: connect failed
"test" is not the correct database, and nothing appears in the log file.
I am at a loss as to what could be wrong. I checked the upstart scripts and they seem fine. /etc/init/mongodb.conf runs:
mongodb --exec /usr/bin/mongod -- --config /etc/mongodb.conf
OK, this all comes down to permissions, but let's take it step by step. When you run sudo mongod it does not load a config file at all, it literally starts with the compiled in defaults - port 27017, database path of /data/db etc. - that is why you got the error about not being able to find that folder. The "Ubuntu default" is only used when you point it at the config file (if you start using the service command, this is done for you behind the scenes).
Next you ran it like this:
sudo mongod -f /etc/mongodb.conf
If there weren't problems before, then there will be now - you have run the process, with your normal config (pointing at your usual dbpath and log) as the root user. That means that there are going to now be a number of files in that normal MongoDB folder with the user:group of root:root.
This will cause errors when you try to start it as a normal service again, because the mongodb user (which the service will attempt to run as) will not have permission to access those root:root files, and most notably, it will probably not be able to write to the log file to give you any information.
Therefore, to run it as a normal service, we need to fix those permissions. First, make sure MongoDB is not currently running as root, then:
cd /var/log/mongodb
sudo chown -R mongodb:mongodb .
cd /var/lib/mongodb
sudo chown -R mongodb:mongodb .
That should fix it up (assuming the user:group is mongodb:mongodb), though it's probably best to verify with an ls -al or similar to be sure. Once this is done you should be able to get the service to start successfully again.
First confirm that the mongodb user/group has permission to write to both the data directory and log file:
$ sudo chown -R mongodb:mongodb /var/lib/mongodb/.
$ sudo chown -R mongodb:mongodb /var/log/mongodb.log
Start up MongoDB as a Daemon (background process) using the following command:
$ mongod --fork --dbpath /var/lib/mongodb/ --smallfiles --logpath
/var/log/mongodb.log --logappend
To Shut Down MongoDB enter the Mongo CLI, access the admin and issue the shutdown command:
$ ./mongo
> use admin
> db.shutdownServer()
Ref: http://www.mongodb.org/display/DOCS/Starting+and+Stopping+Mongo
I too had the same problem. So I went to cd /var/lib/mongodb/ and deleted the mongod.lock file
Then it worked for me.
After checking all permission in the data, journal and log folders as suggested by #nelsonic, my problem was solved by giving permission to lock file in the /tmp folder
sudo chown mongod:mongod mongodb-27017.sock
I was running it as a AWS Amazon Linux instance.
I figured that out by executing as the mongod user as below, and then, researching the error code. It might be useful for other troubleshooting.
sudo -S -u mongod mongod -f /etc/mongod.conf
Just try this command:
sudo chown mongodb /tmp/mongodb-27017.sock
Nothing worked for me, then I've found that it was a permissions problem on /tmp directory:
sudo chmod 1777 /tmp
sudo chown root:root /tmp
None of the above answers worked for me. I finally figured it out by debugging the init script with:
sudo bash -x /etc/init.d/mongodb start
And seeing it was passing the wrong config path to mongod. I simply changed the line in /etc/init.d/mongodb from "CONF=/etc/mongodb.conf" to "CONF=/etc/mongod.conf". Version 2 uses the former, and installing version 3 added /etc/mongod.conf with the new format but apparently did not update the init script.
UPDATE: I now have a much stranger problem where the init script works, but only if I run it with "sudo bash -x /etc/init.d/mongodb start" and not with "sudo service mongodb start". Same thing for stop.
My mongodb was starting when launched from the command line as the mongod user, but not as a service with User=mongod.
After an hour checking permissions, definition of the service, sockets... it was SElinux !
In /etc/selinux/config I switched from enforcing to permissive and reboot. It is now ok.
After none of the above answers worked for me, deleting my log file brought Mongo back to life.
These days this error can occur if you've updated mongod and you are running and old database. Mongod will be using the wiredTiger engine by default and you'll have a mmapv1 database
edit the engine setting in /etc/mongod.conf
# engine: wiredTiger
engine: mmapv1
Careful - YAML is whitespace sensitive
journalctl/systemd won't see this problem. Check the mongod log in /var/log/mongodb/mongod.log
I presume you can convert the database with something like the steps outlined here
https://docs.mongodb.com/manual/tutorial/change-standalone-wiredtiger/