Since the update to couchdb's init script with the bump to couchdb-1.2.1, the couchdb daemon is always runs with root privileges. I propose the attached changes to the init script to fix this bug.
Created attachment 336146 [details, diff] couchdb_init.patch
Created attachment 336148 [details, diff] couchdb_conf.patch
It looks like you have additional changes in the couchdb_conf.patch (wrt COUCHDB_BEAM) that are unrelated, correct?
Yes, you're right, the COUCHDB_BEAM removal is unrelated, I didn't mean to include it. However, there's no point in keeping this variable declaration, as the new init script doesn't need it anymore.
Just tested patch - it works well (with or without COUCHDB_BEAM changes) both on x86 and x86_64 archs. Thanks, Luis! However, after patching there is need to fix permissions for CouchDB directories (/var/{run,lib,log}/couchdb, /etc/couchdb/*) since files there may have root owner and CouchDB will fail to start. All these problems are been noticed in stdout, not in CouchDB logs, so if after patching it wouldn't be run, change COUCHDB_STDOUT_FILE output to somewhere to figure what else need to be fixed.
Yeah, I incorporated this patch in a 1.3.0 ebuild that I've been testing in my overlay, and changing permissions is a bit annoying. Alexander, can you elaborate on how to deal with the notices about the permissions? Also, perhaps you could file an upstream bug about noting these things properly in couch.log.
I've copied the 1.3.0 from my overlay to gentoo-x86.
> Alexander, can you elaborate on how to deal with the notices about the permissions? > > Also, perhaps you could file an upstream bug about noting these things properly in couch.log. Dirkjan, I'd dig into the permissions problem and found that CouchDB behavior is ok: he reports about any eaccess problems in logs as he should. In our case he just unable to do this since root is the owner of couch.log file and couchdb user has no write bit for it. This situation might happen after couchdb-1.2.1 clean install or if logrotate refreshes log file in case of regular upgrade. There is need to be a bit accurate to notice this issue. After fixing logs, every other problem reported well. However, I'd found another one very interesting bug that's not related to init script, but is about database files permissions. Will report about it.
