The startup delay when starting as a service under windows was set to 10
seconds.
This value was fixed and hardcoded since before JetStream. On (some)
Windows systems, this leads to service startup failures, as the store
dir sorting may be hindered by an important load, or slowed down by
increased accesses times, typically from security software influence.
This commit allows overriding the startup delay using an environment
variable NATS_STARTUP_DELAY. This variable is checked outside init() to
allow reporting into the service log.
Any value can be used (even lower than the initial 10s). Bare NATS
start can be far faster than 10s. Ops may want to setup this env var to
lower values in order to trigger an error on stricter constraints.
Trying to run nats-server as nt authority/system user, the process would immediately exit with error: "The service process could not connect to the service controller."
This is now fixed
Changed code on Windows to not use svc code if running in interactive
mode. The original code was running svc.debug.Run() which uses service
code (Execute()) but from the command line. We don't need that.
Also reduced salt on bcrypt password for a config file that started
to cause failures due to test taking too long to finish.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Start the lame duck mode in a go routine in the signal handler
because I think we want to be able to shutdown the server while
in that mode.
Kept the closing as a loop in the lameDuckMode() function (did
not use a timer).
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
When receiving SIGUSR2 signal (or -sl ldm) the server stops
accepting new clients, closes routes connections and spread the
closing of client connections based on a config lame duck duration
(default is 30sec). This will help preventing a storm of client
reconnect when a server needs to be shutdown.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
for the process name and service name. This allows the reuse of this
code in NATS Streaming Server by invoking the new setters to
change the service and process names.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
The use of the `svc` API prevented the NATS Server to run as
a container on both nanoserver and windowsservercore Docker images.
An attempt was made to replace svc.Debug with normal server.Start()
if detected to be interactive, however, that did not work. The
fact of detecting if interactive or not already requires connecting
to the service controller apparently.
This change looks up for an environment variable (NATS_DOCKERIZED)
and if set to "1", will not make use of the `svc` package.
This environment variable will be set in the Docker image (in
nats-docker/windows/nanoserver/Dockerfile and windowsservercore/Dockerfile).
Resolves#543
