couchdb 1.0.1 Hang during startup

[jeff-macports@…]

Couchdb will hang during startup. Beam is left running, but the network port is not opened and no error messages are produced. Experienced on multiple systems. All ports up to date as of 2010-12-15 13:40 CST. Performed full removal of entire macports environment, reinstalled and rebuilt all ports to no effect.

I was able to restore normal function by installing erlang with the ssl variant. I believe this was caused by [74027] which now builds erlang without ssl, whereas before it would build with ssl since the incorrect flags were being used.

[tshead@…]

I've run into the same problem and can confirm that reinstalling erlang with ssl enabled solves the issue.

[stefan+macports@…]

I've run into the same problem with couchdb @1.0.2_0. A beam.smp process would start up but not be listening on any TCP port (like, the one specified under httpd in default.ini). Installing erlang +ssl fixed it.

CouchDB was the very first MacPort I installed on this system so there's nothing but couchdb and its dependencies in my ports here. The default erlang variant has no ssl and couchdb didn't run; I searched the web, found this ticket, and installed erlang +ssl; now couchdb is listening on the default port and I can browse futon.

[trevor.bain@…]

Cc Me!

[trevor.bain@…]

I guess this is the wrong venue to ask this, but:

Can't macports require a variant for a dependency? And, if so, wouldn't the fix be to depend on the +ssl variant in couchdb. I'm gonna assume both of these statements are true and look into how to propose a patch to a port owner (off to RTFM).

[jeff-macports@…]

Replying to trevor.bain@…:

Can't macports require a variant for a dependency? And, if so, wouldn't the fix be to depend on the +ssl variant in couchdb. I'm gonna assume both of these statements are true and look into how to propose a patch to a port owner (off to RTFM).

I don't believe it is possible. In fact, there is an open ticket from a very long time ago (#126) about that topic that appears to still be unresolved.

I think the best option here is to file a ticket with the erlang maintainer to add +ssl as a default variant. Since it was (incorrectly) building it that way before, it should be the default now since other ports, like couchdb, were depending on that behavior. Alternately, a patch could be included in the portfile for couchdb that disables ssl support and add a variant for that in couchdb that could check for the existence of some part of erlang that indicates ssl support and error out if it isn't there.

[bfulgham@…]

Erlang now builds with +ssl as default.