I've upgraded my varnish from 6.2.x to 6.6.x. Amost everyting works Ok, but no reload.
After "start" ps show:
root 10919 0.0 0.0 18960 5288 ? Ss 22:38 0:00 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -p thread_pools=8 -p thread_pool_min=100 -p thread_pool_max=4000 -p workspace_client=128k -p workspace_backend=128k -l 200m -S /etc/varnish/secret -s malloc,256m -s static=file,/data/varnish_storage.bin,80g
now I try to reload:
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Rd auth 0124ef9602b9e6aad2766e52755d02a0d17cd6cfe766304761d21ea058bd8b3b
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Wr 200 -----------------------------#012Varnish Cache CLI 1.0#012-----------------------------#012Linux,5.4.0-107-generic,x86_64,-junix,-smalloc,-sfile,-sdefa
ult,-hcritbit#012varnish-6.6.1 revision e6a8c860944c4f6a7e1af9f40674ea78bbdcdc66#012#012Type 'help' for command list.#012Type 'quit' to close CLI session.
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Rd ping
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Wr 200 PONG 1649450530 1.0
Apr 8 22:42:10 xxx varnishd[10919]: CLI telnet 127.0.0.1 5282 127.0.0.1 6082 Rd vcl.load reload_20220408_204210_11818 /etc/varnish/default.vcl
Apr 8 22:42:15 xxx varnishreload[11818]: VCL 'reload_20220408_204210_11818' compiled
Apr 8 22:42:20 xxx varnishreload[11818]: Command: varnishadm -n '' -- vcl.use reload_20220408_204210_11818
Apr 8 22:42:20 xxx varnishreload[11818]: Rejected 400
Apr 8 22:42:20 xxx varnishreload[11818]: CLI communication error (hdr)
Apr 8 22:42:20 xxx systemd[1]: varnish.service: Control process exited, code=exited, status=1/FAILURE
Apr 8 22:42:20 xxx systemd[1]: Reload failed for Varnish Cache, a high-performance HTTP accelerator.
and now ps shows:
vcache 10919 0.0 0.0 19048 5880 ? SLs 22:38 0:00 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -p thread_pools=8 -p thread_pool_min=100 -p thread_pool_max=4000 -p workspace_client=128k -p workspace_backend=128k -l 200m -S /etc/varnish/secret -s malloc,256m -s static=file,/data/varnish_storage.bin,80g
vcache 10959 0.4 0.2 84585576 23088 ? SLl 22:39 0:01 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -p thread_pools=8 -p thread_pool_min=100 -p thread_pool_max=4000 -p workspace_client=128k -p workspace_backend=128k -l 200m -S /etc/varnish/secret -s malloc,256m -s static=file,/data/varnish_storage.bin,80g
I see process owner was changed to vcache. What is wrong with it? anoder reload will fail too with same reject code.
Can you try removing -j unix,user=vcache from your varnishd runtime command. If I remember correctly, Varnish will automatically drop privileges on the worker process without really needing to explicitly set jailing settings.
If that doesn't work, please also explain which commands you used to start Varnish and reload Varnish.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 months ago.
Improve this question
I would like to install the most recent tinyproxy version 1.11.0 on Ubuntu. How can I do that?
Unfortunetly does sudo apt update; sudo apt install tinyproxy -y; not work for me and only gives me the most recent stable version 1.10.0 from 2018.
So I tried to download and unzip the most recent version on GitHub
https://github.com/tinyproxy/tinyproxy/releases
But I couldn't get it to work properly installed yet.
What I tried so far:
sudo apt update;
... [loading the unzipped tinyproxy 1.11.0 folder via own GitHub repo]
cd OwnGitHubRepo/tinyproxy-1.11.0
sudo apt-get install build-essential -y
sudo apt install autoconf -y
autoconf
./configure
make
sudo make install
The installation seems to have been working somehow as tinyproxy -v returns: tinyproxy 1.11.0
But I now can not run following command which I would usually do:
sudo /etc/init.d/tinyproxy restart;
As there is no tinyproxy folder inside /etc/ listed yet. :/
(Also sudo lsof -i:8888 doesn't show any listing server yet)
Documentations:
http://tinyproxy.github.io/
Tried under AWS EC2 Ubuntu Server 20.04 LTS (HVM), SSD Volume Type
Make sure you update the system with the latest packages
ubuntu#ip-172-30-2-209:~$ sudo su -
root#ip-172-30-2-209:~#
root#ip-172-30-2-209:~# apt-get update
root#ip-172-30-2-209:~# apt-get dist-upgrade
You can reboot the server if a new kernel is available
root#ip-172-30-2-209:~# reboot
Install the build tools:
root#ip-172-30-2-209:~# apt-get install build-essential
root#ip-172-30-2-209:~# apt-get install autoconf
Download the source code and build the software
root#ip-172-30-2-209:~# wget https://github.com/tinyproxy/tinyproxy/releases/download/1.11.0/tinyproxy-1.11.0.tar.bz2
root#ip-172-30-2-209:~# tar -jxvf tinyproxy-1.11.0.tar.bz2
root#ip-172-30-2-209:~# cd tinyproxy-1.11.0/
root#ip-172-30-2-209:~/tinyproxy-1.11.0# ./configure
root#ip-172-30-2-209:~/tinyproxy-1.11.0# make
root#ip-172-30-2-209:~/tinyproxy-1.11.0# make install
Important directories/files to track:
/usr/bin/mkdir -p '/usr/local/bin'
/usr/bin/install -c tinyproxy '/usr/local/bin'
/usr/bin/mkdir -p '/usr/local/share/tinyproxy'
/usr/bin/install -c -m 644 debug.html default.html stats.html '/usr/local/share/tinyproxy'
/usr/bin/mkdir -p '/usr/local/etc/tinyproxy'
/usr/bin/install -c -m 644 tinyproxy.conf '/usr/local/etc/tinyproxy'
/usr/bin/mkdir -p '/usr/local/share/man/man5'
/usr/bin/install -c -m 644 tinyproxy.conf.5 '/usr/local/share/man/man5'
/usr/bin/mkdir -p '/usr/local/share/man/man8'
/usr/bin/install -c -m 644 tinyproxy.8 '/usr/local/share/man/man8'
/usr/bin/mkdir -p '/usr/local/share/doc/tinyproxy'
/usr/bin/install -c -m 644 AUTHORS NEWS README README.md '/usr/local/share/doc/tinyproxy'
Configure the software
Symlink the configuration folder
root#ip-172-30-2-209:~/tinyproxy-1.11.0# ln -s /usr/local/etc/tinyproxy /etc/
root#ip-172-30-2-209:~/tinyproxy-1.11.0# ls -la /etc/ | grep tinyproxy
lrwxrwxrwx 1 root root 24 Apr 3 09:53 tinyproxy -> /usr/local/etc/tinyproxy
Check the nobody user group
root#ip-172-30-2-209:~/tinyproxy-1.11.0# cat /etc/passwd | grep nobody
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
root#ip-172-30-2-209:~/tinyproxy-1.11.0# cat /etc/group | grep 65534
nogroup:x:65534:
Since nobody is assigned to the nogroup group, change the Group element in tinyproxy config from nobody group to nogroup
root#ip-172-30-2-209:~/tinyproxy-1.11.0# sed -i s/'Group nobody'/'Group nogroup'/g /etc/tinyproxy/tinyproxy.conf
Configure the rest of tinyproxy to your expectations (here is the minimal setup)
root#ip-172-30-2-209:~/tinyproxy-1.11.0# cat /etc/tinyproxy/tinyproxy.conf | grep -v "^#\|^$"
User nobody
Group nogroup
Port 8888
Timeout 600
DefaultErrorFile "/usr/local/share/tinyproxy/default.html"
StatFile "/usr/local/share/tinyproxy/stats.html"
LogLevel Info
MaxClients 100
Allow 127.0.0.1
Allow ::1
ViaProxyName "tinyproxy"
Test the connection
root#ip-172-30-2-209:~/tinyproxy-1.11.0# tinyproxy -d -c /etc/tinyproxy/tinyproxy.conf
NOTICE Apr 03 09:56:13.294 [8179]: Initializing tinyproxy ...
NOTICE Apr 03 09:56:13.294 [8179]: Reloading config file
INFO Apr 03 09:56:13.294 [8179]: Setting "Via" header to 'tinyproxy'
NOTICE Apr 03 09:56:13.294 [8179]: Reloading config file finished
INFO Apr 03 09:56:13.294 [8179]: listen_sock called with addr = '(NULL)'
INFO Apr 03 09:56:13.294 [8179]: trying to listen on host[0.0.0.0], family[2], socktype[1], proto[6]
INFO Apr 03 09:56:13.294 [8179]: listening on fd [3]
INFO Apr 03 09:56:13.294 [8179]: trying to listen on host[::], family[10], socktype[1], proto[6]
INFO Apr 03 09:56:13.294 [8179]: listening on fd [4]
INFO Apr 03 09:56:13.294 [8179]: Now running as group "nogroup".
INFO Apr 03 09:56:13.294 [8179]: Now running as user "nobody".
INFO Apr 03 09:56:13.294 [8179]: Setting the various signals.
INFO Apr 03 09:56:13.294 [8179]: Starting main loop. Accepting connections.
CTRL+C
Create a service to run tinyproxy
root#ip-172-30-2-209:~/tinyproxy-1.11.0# nano /lib/systemd/system/tinyproxy.service
[Unit]
Description=tinyproxy service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=nobody
Group=nogroup
ExecStart=/usr/local/bin/tinyproxy -d -c /etc/tinyproxy/tinyproxy.conf
[Install]
WantedBy=multi-user.target
Start the service and check if everything is working fine
root#ip-172-30-2-209:~/tinyproxy-1.11.0# systemctl enable tinyproxy.service
Created symlink /etc/systemd/system/multi-user.target.wants/tinyproxy.service → /lib/systemd/system/tinyproxy.service.
root#ip-172-30-2-209:~/tinyproxy-1.11.0# systemctl status tinyproxy.service
● tinyproxy.service - tinyproxy service
Loaded: loaded (/lib/systemd/system/tinyproxy.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2022-04-03 10:00:20 UTC; 5s ago
Main PID: 8236 (tinyproxy)
Tasks: 1 (limit: 1145)
Memory: 1.0M
CGroup: /system.slice/tinyproxy.service
└─8236 /usr/local/bin/tinyproxy -d -c /etc/tinyproxy/tinyproxy.conf
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: Setting "Via" header to 'tinyproxy'
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: NOTICE Apr 03 10:00:20.980 [8236]: Reloading config file finished
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: listen_sock called with addr = '(NULL)'
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: trying to listen on host[0.0.0.0], family[2], socktype[1], proto[6]
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: listening on fd [3]
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: trying to listen on host[::], family[10], socktype[1], proto[6]
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: listening on fd [4]
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: Not running as root, so not changing UID/GID.
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: Setting the various signals.
Apr 03 10:00:20 ip-172-30-2-209 tinyproxy[8236]: INFO Apr 03 10:00:20.980 [8236]: Starting main loop. Accepting connections.
Install net-tools to check the listening ports
root#ip-172-30-2-209:~/tinyproxy-1.11.0# apt-get install net-tools
root#ip-172-30-2-209:~/tinyproxy-1.11.0# netstat -napt | grep LISTEN | grep tinyproxy
tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN 8236/tinyproxy
tcp6 0 0 :::8888 :::* LISTEN 8236/tinyproxy
root#ip-172-30-2-209:~/tinyproxy-1.11.0# lsof -i:8888
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tinyproxy 8236 nobody 3u IPv4 34119 0t0 TCP *:8888 (LISTEN)
tinyproxy 8236 nobody 4u IPv6 34120 0t0 TCP *:8888 (LISTEN)
Extras
a) Logging and Pid file
Prepare pid and log directories
root#ip-172-30-2-209:~/tinyproxy-1.11.0# mkdir /var/run/tinyproxy/
root#ip-172-30-2-209:~/tinyproxy-1.11.0# mkdir /var/log/tinyproxy/
root#ip-172-30-2-209:~/tinyproxy-1.11.0# chown -R nobody:nogroup /var/run/tinyproxy/
root#ip-172-30-2-209:~/tinyproxy-1.11.0# chown -R nobody:nogroup /var/log/tinyproxy/
Add pid and log parameters into tinyproxy config
root#ip-172-30-2-209:~/tinyproxy-1.11.0#
root#ip-172-30-2-209:~/tinyproxy-1.11.0# cat /etc/tinyproxy/tinyproxy.conf | grep ^LogFile
LogFile "/var/log/tinyproxy/tinyproxy.log"
root#ip-172-30-2-209:~/tinyproxy-1.11.0# cat /etc/tinyproxy/tinyproxy.conf | grep ^PidFile
PidFile "/var/run/tinyproxy/tinyproxy.pid"
Restart service
root#ip-172-30-2-209:~/tinyproxy-1.11.0# systemctl restart tinyproxy.service
b) Process limits
root#ip-172-30-2-209:~# ps aux | grep tinyproxy
nobody 64427 9.8 0.5 789836 10232 ? Ssl 12:11 0:00 /usr/local/bin/tinyproxy -d -c /etc/tinyproxy/tinyproxy.conf
root 65436 0.0 0.0 7696 644 pts/0 S+ 12:11 0:00 grep --color=auto tinyproxy
root#ip-172-30-2-209:~# cat /proc/64427/limits | grep "Max processes\|Max open files"
Max processes 7151 7151 processes
Max open files 1024 524288 files
To bump up those, edit the /lib/systemd/system/tinyproxy.service file and add the following lines in the [Service] section
[Service]
...
LimitNOFILE=700000
LimitNPROC=700000
...
Then reload systemd and restart the service
root#ip-172-30-2-209:~# systemctl daemon-reload
root#ip-172-30-2-209:~# systemctl restart tinyproxy.service
Check the results
root#ip-172-30-2-209:~# ps axu | grep tinyproxy
nobody 68439 0.6 0.1 533092 3068 ? Ssl 12:13 0:00 /usr/local/bin/tinyproxy -d -c /etc/tinyproxy/tinyproxy.conf
root 68490 0.0 0.0 7696 656 pts/0 S+ 12:13 0:00 grep --color=auto tinyproxy
root#ip-172-30-2-209:~# cat /proc/68439/limits | grep "Max processes\|Max open files"
Max processes 700000 700000 processes
Max open files 700000 700000 files
I have installed opensips-2.1.2 in on vmware (ubuntu 14.4.6).
I can see opensips installation went fine, but not able to access the web interface for the same.
After installation i have greped the process to confirm if it got installed or not, it looks fine from here
opensips 19881 3641 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19882 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19883 19881 0 11:42 ? 00:00:05 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19884 19881 0 11:42 ? 00:00:01 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19885 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19886 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19887 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
opensips 19888 19881 0 11:42 ? 00:00:00 /usr/local/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -M 8 -u opensips -g opensips
root 23310 4465 0 12:05 pts/4 00:00:00 grep --color=auto opensips```
Please help me, what is blocking me to access the same on web interface.
Installing the "opensips-2.1.2" package will only provide the OpenSIPS SIP server, which will process the incoming SIP traffic.
The OpenSIPS Control Panel is a separate project, meant to be accessed via a web server, such as Apache or Nginx. Its purpose is to help system administrators provision various data for OpenSIPS to work with. See the available install options here.
Running any of the commands varnishstat, varnishhist, varnishlog, varnishtop will give the error message as
Could not get hold of varnishd, is it running?
Below is some information for understanding.
sudo service varnish status
varnish.service - Varnish Cache, a high-performance HTTP accelerator
Loaded: loaded (/lib/systemd/system/varnish.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2017-11-15 15:28:04 UTC; 1h 16min ago
Process: 10235 ExecStart=/usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m (code=ex
Main PID: 10251 (varnishd)
Tasks: 217
Memory: 106.2M
CPU: 1.673s
CGroup: /system.slice/varnish.service
├─10251 /usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
└─10271 /usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
Nov 15 15:28:03 varnish1 systemd[1]: Starting Varnish Cache, a high-performance HTTP accelerator...
Nov 15 15:28:04 varnish1 varnishd[10235]: Debug: Platform: Linux,4.11.0-1014-azure,x86_64,-junix,-smalloc,-smalloc,-hcritbit
Nov 15 15:28:04 varnish1 varnishd[10251]: Platform: Linux,4.11.0-1014-azure,x86_64,-junix,-smalloc,-smalloc,-hcritbit
Nov 15 15:28:04 varnish1 varnishd[10235]: Debug: Child (10271) Started
Nov 15 15:28:04 varnish1 varnishd[10251]: Child (10271) Started
Nov 15 15:28:04 varnish1 varnishd[10251]: Child (10271) said Child starts
Nov 15 15:28:04 varnish1 systemd[1]: Started Varnish Cache, a high-performance HTTP accelerator.
sudo service varnishd status
varnishd.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
sudo service varnishd start
Failed to start varnishd.service: Unit varnishd.service not found.
varnishd -V
varnishd (varnish-5.2.1 revision 67e562482)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2015 Varnish Software AS
Answer:
sudo varnishstat
sudo varnishhist
sudo varnishlog
sudo varnishtop
If you’re using Varnish utilities as unprivileged user, you’re probably missing privileges to execute some actions. For some distros, it’s enough to add yourself to Varnish’s group:
gpasswd -a my_user varnish
Then put the new group in use and at least varnishstat should work.
If sudo varnishstat doesn't help: check if varnish is started
sudo /etc/init.d/varnish start
Following worked fine for me:
sudo varnishadm
Found this thread, however the answers here did not help.
As per: http://lists.varnish-cache.org/pipermail/varnish-misc/2020-July/026914.html when you have updated the serverhostname, you need a full server reboot.
Using Apache2 on Linux, I get this error message when trying to start it.
$ sudo /usr/local/apache2/bin/apachectl start
httpd not running, trying to start
(98)Address already in use: make_sock: unable to listen for connections on address 127.0.0.1:80
no listening sockets available, shutting down
Unable to open logs
$ sudo /usr/local/apache2/bin/apachectl stop
httpd (no pid file) not running
Some facts:
This is one of the last lines in my Apache logs:
[Mon Jun 19 18:29:01 2017] [warn] pid file /usr/local/apache2/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run?
My '/usr/local/apache2/conf/httpd.conf' contains
Listen 127.0.0.1:80
I have "Listen 80" configured at '/etc/apache2/ports.conf'
Disk is not full
I've checked that I do not have two or more "Listen" at '/usr/local/apache2/conf/httpd.conf'
Some outputs:
$ sudo ps -ef | grep apache
root 1432 1 0 17:35 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 1435 1432 0 17:35 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 1436 1432 0 17:35 ? 00:00:00 /usr/sbin/apache2 -k start
myuserr 1775 1685 0 17:37 pts/1 00:00:00 grep --color=auto apache
$ sudo grep -ri listen /etc/apache2
/etc/apache2/apache2.conf:# supposed to determine listening ports for incoming connections which can be
/etc/apache2/apache2.conf:# Include list of ports to listen on
/etc/apache2/ports.conf:Listen 80
/etc/apache2/ports.conf: Listen 443
/etc/apache2/ports.conf: Listen 443
What can I do to restart Apache? Should I repair 'httpd.pid'?
This error means that something already uses 80 port.
If you really don't have 2 line of Listen 80 in apache configurations then execute this command to see what uses 80 port: netstat -antp | grep 80.
I fixed it by killing the three processes
root 1621 1 0 18:46 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 1624 1621 0 18:46 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 1625 1621 0 18:46 ? 00:00:00 /usr/sbin/apache2 -k start
However, each time I want to reboot my server, I must kill thee processes. What is starting them?
I created a database "my_new_database" and "albums", neither of which I can DELETE. I believe I am still in "ADMIN" party mode. To demonstrate my issue Ill just post some info below.
First here is to show couchdb running ( started using the SystemV script via service )
$ ps aux | grep couch
couchdb 2939 0.0 0.2 108320 1528 ? S 20:45 0:00 /bin/sh -e /usr/bin/couchdb -a /etc/couchdb/default.ini -a /etc/couchdb/local.ini -b -r 0 -p /var/run/couchdb/couchdb.pid -o /dev/null -e /dev/null -R
couchdb 2950 0.0 0.1 108320 732 ? S 20:45 0:00 /bin/sh -e /usr/bin/couchdb -a /etc/couchdb/default.ini -a /etc/couchdb/local.ini -b -r 0 -p /var/run/couchdb/couchdb.pid -o /dev/null -e /dev/null -R
couchdb 2951 4.8 2.3 362168 14004 ? Sl 20:45 0:00 /usr/lib64/erlang/erts-5.8.5/bin/beam -Bd -K true -A 4 -- -root /usr/lib64/erlang -progname erl -- -home /usr/local/var/lib/couchdb -- -noshell -noinput -sasl errlog_type error -couch_ini /etc/couchdb/default.ini /etc/couchdb/local.ini /etc/couchdb/default.ini /etc/couchdb/local.ini -s couch -pidfile /var/run/couchdb/couchdb.pid -heart
couchdb 2959 0.0 0.0 3932 304 ? Ss 20:45 0:00 heart -pid 2951 -ht 11
ec2-user 2963 0.0 0.1 103424 828 pts/1 S+ 20:45 0:00 grep couch
Here is the output of the ".couch" databases I have ( shown for user ownership and permissions)
$ ls -lat /var/lib/couchdb
-rw-r--r-- 1 couchdb couchdb 23 Oct 11 20:45 couch.uri
drwxr-xr-x 3 couchdb couchdb 4096 Oct 11 19:35 .
-rw-r--r-- 1 couchdb couchdb 79 Oct 11 19:35 database2.couch
-rwxrwxrwx 1 couchdb couchdb 79 Oct 11 19:00 my_new_database.couch
-rw-r--r-- 1 couchdb couchdb 4182 Oct 4 21:52 albums.couch
-rw-r--r-- 1 couchdb couchdb 79 Oct 4 21:42 albums-backup.couch
-rw-r--r-- 1 couchdb couchdb 4185 Oct 4 21:30 _users.couch
drwxr-xr-x 18 root root 4096 Oct 4 20:58 ..
drwxr-xr-x 2 root root 4096 Oct 4 18:34 .delete
Here is my first attempt to DELETE
$ curl -X DELETE http://127.0.0.1:5984/my_new_database
{"error":"unauthorized","reason":"You are not a server admin."}
And my second attempt using an authenticated user.
$ curl -X DELETE http://brian:brian#127.0.0.1:5984/my_new_database
{"error":"error","reason":"eacces"}
The username/password of brian/brian was added to the [admin] section of /etc/couchdb/local.ini
Here is the output of my "_users" file. The "key" and "id" fields confuse me.
$ curl -X GET http://brian:brian#127.0.0.1:5984/_users/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"_design/_auth","key":"_design/_auth","value":{"rev":"1-c44fb12a2676d481d235523092e0cec4"}}
]}
Have you restarted your CouchDB after you added to user to local.ini? If so, has the password in the file been hashed or is it readable?
Generally your file permissions look OK, so I can't tell what exactly causes the error. For a quick fix you can simply delete the .couch file, though.
This question is really old, but since I got bitten by this today and this is where Google led me, I thought I'd share my solution for others that stumble here. In my case, my Couch lib directory (/usr/local/var/lib/couchdb for me) had a directory called .delete that was owned by root. Changing the owner to couchdb let me delete databases again.