ssbc / multiserver

A single interface that can work with multiple protocols, and multiple transforms of those protocols (eg, security layer)
MIT License
105 stars 28 forks source link

Two ssb-servers with plugin/unix-socket cannot run at the same time #73

Open elavoie opened 2 years ago

elavoie commented 2 years ago

Commit faa9526ce8ded7d9a278ef70e95df82f56864072 introduced a module-level variable started (l.6-l.7) that is used to avoid reinitializing the unix socket twice. Unfortunately, when the plugin is used in two different Secret-Stacks running within the same node process, e.g. in unit tests, this strategy prevents the second instance from being initialized properly and is therefore ignored.

Moreover, l.27 returns undefined and therefore upon closing, the second instance fails with the following error:

.../node_modules/multiserver/compose.js:33
    if (f.length) return f(cb)
          ^

TypeError: Cannot read property 'length' of undefined
    at fnAsAsync (.../node_modules/multiserver/compose.js:33:11)
    at closeMultiserverServer (.../node_modules/multiserver/index.js:57:37)
    at close (.../node_modules/secret-stack/lib/core.js:259:82)
    at hooked (.../node_modules/hoox/index.js:10:15)
    at .../node_modules/ssb-db/index.js:90:11
    at .../node_modules/flumedb/index.js:263:25
    at .../node_modules/continuable-hash/index.js:25:25
    at Single._written (.../node_modules/async-single/proto.js:46:12)
    at release (.../node_modules/mutexify/index.js:25:13)
    at .../node_modules/atomic-file/inject.js:27:11
npm ERR! Test failed.  See above for more details.

At least, l.27 should be fixed to avoid an error on closing. Better, the check for avoiding duplicate initialization should be specific to a specific instance of Secret-Stack and not module-wide (which is initialized only once for all node module imports).

@arj03

arj03 commented 2 years ago

@elavoie that does indeed sound like a bug.

But maybe some context on why other people have not run into the same problem. The unix socket is often used together with no-auth for a much faster local ssb-client connection to the ssb server. Not for communication between ssb servers.

Is the reason you have multiple secret stacks that you want to test network or replication? Then maybe have a look at https://github.com/ssbc/ssb-replication-scheduler/tree/main/test/integration and https://github.com/ssbc/ssb-ebt/blob/master/test/server.js.

elavoie commented 2 years ago

@arj03 I did not succeed using unix-sockets for replication between multiple servers, although I would have a use case for it: on institutional Wifi connections, such as Eduroam used by many universities, all ports are usually blocked to prevent inter-process communication even between processes on the same machine. That prevents automatic connection using ssb-lan and the net interface. So if I had an alternative, unix sockets or others, that would be great.

The problem in my case arise not because of that need, but because I use a single setup for Secret-Stack both for tests and actual deployments with all the plugins installed. I wanted to include unix-socket, following the conventions of ssb-server, but because of the error mentioned, the error prevents graceful closing after launching two servers from the same process for unit testing.