sname is short for 'short name', i'm not sure how it works if you give it a fully qualified hostname (the '@localhost' bit). Remember you also need to supply the right cookie (read from ~/.erlang.cookie if you didn't specify with -setcookie).
On 17 July 2013 16:09, Alexander Shorin <[email protected]> wrote: > Actually that was first thing what I'd done before made any attempts > to connect to Erlang node. > By instead of -name [email protected] I'd set -sname > 'couchdb@localhost' - is there principal difference between them? > -- > ,,,^..^,,, > > > On Wed, Jul 17, 2013 at 1:20 PM, Robert Newson <[email protected]> wrote: >> CouchDB does not, by default, run as a distributed Erlang node, which >> explains the failure to connect (it's not listening). >> >> You can add '-name [email protected]' or similar to the startup >> options to change that. >> >> B. >> >> >> On 17 July 2013 08:45, Alexander Shorin <[email protected]> wrote: >>> Hi there, >>> >>> I just tried to run etop against CouchDB inspired by one G+ post that >>> provided shortcut script. I'd added -sname 'couchdb@localhost' (yes, >>> with single quotes around the node name) argument for CouchDB startup >>> and successfully located erlang cookie within couchdb user home dir >>> (/var/lib/couchdb for me). >>> >>> The result command to run etop was looked as: >>> >>> erl -name etop-`date +%s` -hidden -s etop -s erlang halt \ >>> -output text -node [email protected] -setcookie secret \ >>> -tracing off -sort msg_q -interval 5 >>> >>> But it had failed with an error: >>> >>> Erlang R16B (erts-5.10.1) [source] [64-bit] [smp:4:4] [async-threads:10] >>> >>> Eshell V5.10.1 (abort with ^G) >>> ([email protected])1> Error Couldn't connect to node >>> '[email protected]' >>> >>> and CouchDB didn't log any error messages about unwelcome connections >>> from outside. I couldn't use couchdb@localhost for -node argument >>> since it produce invalid node name error. Using long node name also >>> was with no luck. >>> >>> Actually, I'd successfully solve my problem with entop[1] help, but >>> wonder why erl command ahd failed to connect? Probably, entop handles >>> connection right somewhere deep in sources and I feel the problem is >>> too trivial, but looks I'd missed something... >>> >>> [1]: https://github.com/mazenharake/entop >>> >>> >>> -- >>> ,,,^..^,,,
