Skip to content

please support multi-port config.json #5

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

Closed
wisicn opened this issue May 25, 2013 · 8 comments
Closed

please support multi-port config.json #5

wisicn opened this issue May 25, 2013 · 8 comments

Comments

@wisicn
Copy link

wisicn commented May 25, 2013

I tried the following config.json, but always failed, the ss-server always promote me to input parameters and show me usage.

{
"server":"0.0.0.0",
"port_password": {
"8387": "foobar2",
"8388": "foobar1"
},
"timeout":60,
"method":"rc4"
}

@wisicn
Copy link
Author

wisicn commented May 25, 2013

@madeye
Copy link
Contributor

madeye commented May 25, 2013

Sorry, we have no plan to support multi port configuration. Actually you can use multiple instances instead. For example:

ss-server -c config1.json -f pid1
ss-server -c config2.json -f pid2
ss-server -c config3.json -f pid3

As the best practice we recommend for shadowsocks-libev, it helps to isolate each user in different processes and reconfigure each user's port/password/encyption/timeout without reload/restart the whole service. Furthermore, this approach enables us to manage users with legacy control panels, for example old SSH / VHOST panels with each user's ss-server running in its own space.

Compared to other implementations, shadowsocks-libev uses much fewer resources (about 1MB memory and hundreds of file descriptors in a typical usage) . As a result, this kind of multi processes should only introduce slight overhead and even works well for low end boxes.

@madeye madeye closed this as completed May 25, 2013
@wisicn
Copy link
Author

wisicn commented May 25, 2013

OK. your comments make it very clear to me. I will use multiple instances.
thanks your help again and thanks your perfect shadowsocks-libev very much.

@pexcn
Copy link
Contributor

pexcn commented Mar 22, 2015

Thanks.

@nielspeen
Copy link

Running multiple instances is not feasible when supporting thousands of users. Is it possible to make shadowsocks start through inetd or xinetd? It would require only minimal changes to shadowsocks and instantly makes it scalable.

(Using the Go version at the moment, but it's not as stable and well-maintained as this libev version.)

simon referenced this issue in ovh/overthebox-shadowsocks-libev Sep 6, 2016
Add libnetfilter-conntrack-dev in dependency
@gnu4cn
Copy link

gnu4cn commented Nov 15, 2016

@addohm
Copy link

addohm commented Oct 8, 2018

Sorry, we have no plan to support multi port configuration. Actually you can use multiple instances instead. For example:

ss-server -c config1.json -f pid1
ss-server -c config2.json -f pid2
ss-server -c config3.json -f pid3

As the best practice we recommend for shadowsocks-libev, it helps to isolate each user in different processes and reconfigure each user's port/password/encyption/timeout without reload/restart the whole service. Furthermore, this approach enables us to manage users with legacy control panels, for example old SSH / VHOST panels with each user's ss-server running in its own space.

Compared to other implementations, shadowsocks-libev uses much fewer resources (about 1MB memory and hundreds of file descriptors in a typical usage) . As a result, this kind of multi processes should only introduce slight overhead and even works well for low end boxes.

How do you configure multiple instances as a service? The wiki couldn't be more general :D

@oakaigh
Copy link
Contributor

oakaigh commented Oct 20, 2018

@wisicn Try ss-manager and just dump your original json config file to the destination directory if you don't really care about changing service type from forking (ss-server) to simple (ss-manager) and a systemctl daemon-reload.
@addohm What about creating a oneshot systemd service?

But what I was thinking is that ss-local ss-tunnel should have features like multi-port configuration for build-in load balancing (in case servers won't be blocked because of large amount of traffic; GFW has some creepy rules) -- that's another story though.

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

7 participants