Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
elavoie opened this issue Sep 22, 2022 · 2 comments
Open

Comments

@elavoie
Copy link

elavoie commented Sep 22, 2022

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 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
Copy link
Member

arj03 commented Sep 23, 2022

@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
Copy link
Author

elavoie commented Sep 23, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants