[bug] PM2 doesn't pass through command line arguments on Windows about soketi HOT 12 OPEN

Damn, Windows striking again 🥲

from soketi.

I am using soketi 0.30.2 an I can confirm that the following won't work:

soketi-pm2 start --config=soketi.config.json

It simply ignores any command-line arguments passed to.

from soketi.

Have you tried the following variant: yargs/yargs#1038 ?

from soketi.

I've tried that using the following:

pm2 start /usr/bin/soketi-pm2 -- --config="/home/vagrant/soketi.json"

Using DEBUG=1 at the start of the above I can see the config getting dumped out at the start of the command output does not contain any of my config file (my config file also has debug enabled so it not being enabled also means it's not getting loaded)

Simply running soketi-pm2 standalone also reveals this is the case as well and checking out bin/pm2.js I can't see the yargs script getting imported like I can in bin/server.js.

from soketi.

Can't we just use the regular soketi binary with PM2 like this (since it seems to be more stable):

ADAPTER_DRIVER=cluster pm2 start soketi --name soketi --instances max -- start --config=soketi.config.json

Or are there any gotchas that we need to be aware of here?

from soketi.

@adiachenko
When I tried to launch the regular soketi binary via PM2 it actually crashed, unsure if that's the case for you or not.

But from what I'm aware the sokeit-pm2 binary sets a flag in Soketi that tells it that it's running under PM2 and to use PM2 specific stuff when using the cluster adapter.

from soketi.

@Sn0wCrack From what I've understood from a cursory glance at the source code pm2 binary just disables node discovery for rate limiter.

I've tried regular binary with PM2 yesterday from my laptop and it worked just fine receiving and sending messages from several clients, but it's not exactly a production-grade test, of course.

from soketi.

I'm not trying this on the production server where I'm planning to run my application, whereas previously I was running this in a Virtualbox VM (Laravel Homestead):

Some of these issue I also brought up in my discussion thread here: #321

So when I attempt to use the regular soketi in PM2 it seems like every instance assumes the master node position and doesn't attempt to negotiate which ones should be the master node.

This seems to lead to me only receiving some of my websocket requests, despite me being able to see that all of them are processed.

I've got the drivers set to cluster mode and am using all the default settings otherwise.

If I run a single instance under PM2 I don't have this issue.

I then also tried this same thing with soketi-pm2 and using all environment variables for configuration and then the same issue occurred where both processes started and they didn't negotiate for master and I end up receiving only some of my websocket requests.

Is there some additional configuration I need to do here to get them to talk to one another properly? I know about the private network configuration but strangely I don't have the issue of IPC not working on my local Homestead but do on the bare production instance.

from soketi.

@adiachenko When I tried to launch the regular soketi binary via PM2 it actually crashed, unsure if that's the case for you or not.

But from what I'm aware the sokeit-pm2 binary sets a flag in Soketi that tells it that it's running under PM2 and to use PM2 specific stuff when using the cluster adapter.

It does check that. Basically, Cluster/Redis/NATS adapter is needed when running with PM2 as it forks processes differently and there is no way to centralize the connections stored in memory, but soketi does not enforce it.

The Cluster rate limiter is the only one that seeks for PM2 usage and tries to create a master. But I think I need to debug it properly in pm2 as CI testing, it seems, does not cover this edge case that I need to replicate.

from soketi.

Confirmed NOT working (command line arguments are ignored)

This hack works using npm install -g @soketi/soketi

In Debian 11, the npm install goes into /usr/lib/node_modules/@soketi/soketi (using npm -g list to find path)

In bin/pm2.js, change line 7 (hardcoded the config file)

#! /usr/bin/env node

const { Cli } = require('./../dist/cli/cli');

process.title = 'soketi-server';

Cli.startWithPm2({config: '/etc/soketi/config.json'});

Starting this using soketi-pm2 start (or in supervisor) now picks up the /etc/soketi/config.json

from soketi.

I am using soketi 0.30.2 an I can confirm that the following won't work:

soketi-pm2 start --config=soketi.config.json

It simply ignores any command-line arguments passed to.

The simple solution is to run the following command:

pm2 start soketi -- start --config=...

In the next version, the soketi-pm2 will be removed as the soketi CLI works fine with PM2.

from soketi.

@rennokki running

pm2 start soketi -- start --config=C:\Users\test\soketi\config.json

it gives me an error (c:\users\test.pm2\logs)

C:\USERS\test\APPDATA\ROAMING\NPM\SOKETI.CMD:1
@ECHO off
^ 

SyntaxError: Invalid or unexpected token
    at Object.compileFunction (node:vm:360:18)
    at wrapSafe (node:internal/modules/cjs/loader:1078:15)
    at Module._compile (node:internal/modules/cjs/loader:1113:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1203:10)
    at Module.load (node:internal/modules/cjs/loader:1027:32)
    at Module._load (node:internal/modules/cjs/loader:868:12)
    at Object.<anonymous> (C:\Users\test\AppData\Roaming\npm\node_modules\pm2\lib\ProcessContainerFork.js:33:23)
    at Module._compile (node:internal/modules/cjs/loader:1149:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1203:10)
    at Module.load (node:internal/modules/cjs/loader:1027:32)
C:\USERS\test\APPDATA\ROAMING\NPM\SOKETI.CMD:1
@ECHO off
^

in pm2 list on status is shown "errored"

I am using win 10, npm 8.19.2 (node 18.10.0), [email protected], [email protected]

Any idea why ?

Using

soketi start --config=C:\Users\test\soketi\config.json

works

from soketi.