You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The start command conveniently launches a cluster (server + workers), but it makes it a bit cumbersome to stop the cluster.
For a short term, hacky solution, a simple killall on Linux could solve it, or the start command could run the server in-process, so that it would block while the server lives.
But in general I think that the server should have a more general and graceful option to stop itself, defined in its API.
Proposal:
The stop event would stop all the connected workers and then shutdown the server.
The command could look like this: rain stop server:1234
It would probably make sense to stop individual workers too, possibly with the same command and a --worker flag.
The ability for clients to shutdown the server is a non-issue from a security standpoint, since there is already no client authentication and the cluster supposes that it's run in a trusted environment.
There could also be an option for a "soft stop", that would cause the server to stop scheduling tasks, but it would first wait for the current in-progress tasks to finish (and maybe checkpoint them to disk) before stopping the cluster.
The text was updated successfully, but these errors were encountered:
When "rain start" is executed, it creates a file (e.g. 'rain.env') with information about started processes.
When "rain stop" is executed then it reads the file and terminates all processes that was spawn.
The existence of file makes also quite easy to stop (or start a new!) worker.
It is not difficult to implement it; however, I have now different priorities and "killall rain" is quite good enough :)
But if someone wants to do it, PR is very welcome:)
The
start
command conveniently launches a cluster (server + workers), but it makes it a bit cumbersome to stop the cluster.For a short term, hacky solution, a simple
killall
on Linux could solve it, or the start command could run the server in-process, so that it would block while the server lives.But in general I think that the server should have a more general and graceful option to stop itself, defined in its API.
Proposal:
The stop event would stop all the connected workers and then shutdown the server.
The command could look like this:
rain stop server:1234
It would probably make sense to stop individual workers too, possibly with the same command and a
--worker
flag.The ability for clients to shutdown the server is a non-issue from a security standpoint, since there is already no client authentication and the cluster supposes that it's run in a trusted environment.
There could also be an option for a "soft stop", that would cause the server to stop scheduling tasks, but it would first wait for the current in-progress tasks to finish (and maybe checkpoint them to disk) before stopping the cluster.
The text was updated successfully, but these errors were encountered: