couchdb spams the logs every 5 seconds when started for the first time due to no _users db

[denyeart]

Description

This issue is re-created from https://issues.apache.org/jira/browse/COUCHDB-3163.
The issue still occurs on recent versions of CouchDB.

Starting couchdb 2.0 for the first time spams the logs every 5 seconds, until it's configured for cluster or single mode operation, due to the lack of _users database:

[notice] 2019-02-27T19:10:00.321412Z nonode@nohost <0.322.0> -------- chttpd_auth_cache changes listener died database_does_not_exist at mem3_shards:load_shards_from_db/6(line:395) <= mem3_shards:load_shards_from_disk/1(line:370) <= mem3_shards:load_shards_from_disk/2(line:399) <= mem3_shards:for_docid/3(line:86) <= fabric_doc_open:go/3(line:38) <= chttpd_auth_cache:ensure_auth_ddoc_exists/2(line:187) <= chttpd_auth_cache:listen_for_changes/1(line:134)
[error] 2019-02-27T19:10:00.321444Z nonode@nohost emulator -------- Error in process <0.323.0> with exit value:
{database_does_not_exist,[{mem3_shards,load_shards_from_db,"_users",[{file,"src/mem3_shards.erl"},{line,395}]},{mem3_shards,load_shards_from_disk,1,[{file,"src/mem3_shards.erl"},{line,370}]},{mem3_shards,load_shards_from_disk,2,[{file,"src/mem3_shards.erl"},{line,399}]},{mem3_shards,for_docid,3,[{file,"src/mem3_shards.erl"},{line,86}]},{fabric_doc_open,go,3,[{file,"src/fabric_doc_open.erl"},{line,38}]},{chttpd_auth_cache,ensure_auth_ddoc_exists,2,[{file,"src/chttpd_auth_cache.erl"},{line,187}]},{chttpd_auth_cache,listen_for_changes,1,[{file,"src/chttpd_auth_cache.erl"},{line,134}]}]}

Steps to Reproduce

Start the official CouchDB docker image.

Expected Behaviour

Suggest that a less concerning and more helpful message be used instead, as the current message gives the impression that something very bad is happening and provides no explanation that the system databases must be created, for example from Fauxton UI.

Your Environment

Official CouchDB docker image with CouchDB 2.2.0.

Additional context

[wohali]

Agree that the message is ugly, and something should be done about that. Perhaps it should point to:

http://docs.couchdb.org/en/stable/setup/index.html

and that portion of the documentation enhanced to give a bit more context.

As you note we can't resolve the core problem because we don't know on startup if the node is going to be single node, joined to a new cluster, or joined to an existing cluster, all of which would affect the intended message and outcome. Suppressing the error completely after a single warning isn't useful either, since it could be ignored.

/cc @rnewson @janl any strong feelings on this one?

[jaydoane]

Another possible approach I worked on a while ago is to not start the change listener unless the auth db exists. While it's currently a WIP I could probably get it in shape pretty quickly if there was a strong enough desire by others to see it land.

[jaydoane]

Ready for review