Repository navigation
Two ssb-servers with plugin/unix-socket cannot run at the same time #73
Description
Activity
@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.
@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.
Commit faa9526 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
undefinedand therefore upon closing, the second instance fails with the following error: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