By default, SQLstream s-Server runs as a service. This service is started when you first install s-Server, and will automatically restart each time your server is rebooted.
To stop and start the service, you can use the sysV service commands. The sqlstream user (or any user wanting to control the service) should have sudo privileges.
$ sudo service s-serverd stop
$ sudo service s-serverd start
$ sudo service s-serverd restart
$ sudo service s-serverd xxx
* Usage: s-serverd {start|stop|restart|status} [ {-cp|--with-checkpoint} <checkpoint name>]
$ sudo service s-serverd status
Depending on the operating system, it is increasingly likely that the underlying init system will be systemd rather than sysV. You may still use the sysV service command as shown above, because systemd supports sysV style init commands in compatibility mode.
You can also use the systemd commands:
$ sudo systemctl status s-serverd
● s-serverd.service - LSB: SQLstream s-Server daemon
Loaded: loaded (/etc/init.d/s-serverd; generated)
Active: active (running) since Wed 2020-12-16 10:07:07 UTC; 5min ago
Docs: man:systemd-sysv-generator(8)
Process: 5586 ExecStop=/etc/init.d/s-serverd stop (code=exited, status=0/SUCCESS)
Process: 5795 ExecStart=/etc/init.d/s-serverd start (code=exited, status=0/SUCCESS)
Main PID: 5889 (s-Server)
Tasks: 0 (limit: 4702)
CGroup: /system.slice/s-serverd.service
‣ 5889 /bin/bash /opt/sqlstream/7.1.0.20110-5662bc96/s-Server/bin/s-Server --daemon
Dec 16 10:06:58 myserver systemd[1]: Starting LSB: SQLstream s-Server daemon...
Dec 16 10:06:59 myserver su[5885]: Successful su for vagrant by root
Dec 16 10:06:59 myserver su[5885]: + ??? root:sqlstream
Dec 16 10:06:59 myserver su[5885]: pam_unix(su:session): session opened for user sqlstream by (uid=0)
Dec 16 10:06:59 myserver su[5885]: pam_unix(su:session): session closed for user sqlstream
Dec 16 10:07:07 myserver s-serverd[5795]: * Started s-serverd
Dec 16 10:07:07 myserver systemd[1]: Started LSB: SQLstream s-Server daemon.
$ sudo systemctl stop s-serverd
$ sudo systemctl start s-serverd
$ sudo systemctl restart s-serverd
To start your SQLstream s-Server manually, you need to be logged in as the sqlstream default user. This is the user that you indicated (or created) during the installation process. You can then run the script named “s-Server”, located in the bin directory:
$SQLSTREAM_HOME/bin/s-Server
You can also run the server without logging in as the s-Server default user by using this syntax from the $SQLSTREAM_HOME/bin/ directory.
sudo -u <default user> ./s-Server
The first time you run the server, it creates a checkpoint. Before you run the server for the first time, you cannot restore the catalog because no checkpoint exists.
NOTE: there is a symbolic link s-server which links to s-Server so you don’t need the caps key.
To stop the SQLstream s-Server, type:
!quit
into the SQLstream s-Server terminal window. This will stop the server, create a checkpoint backup of the repository, and close the window.
If there are open client connections to the server (for example, if the user interface is running), the server will alert you and continue running.
If you need to stop the server in spite of open client connections, type:
!kill
into the SQLstream s-Server terminal window. This will force closure of the connections, then stop the server and create a checkpoint backup of the repository.
In the event that neither !quit nor !kill is able to stop the server, you can type Ctrl+C into the SQLstream s-Server terminal window. This will abort the server and shut down the repository, but will not create the checkpoint backup of the repository. When you next restart the server, it will restore the previous checkpoint backup, so any changes made to repository objects since then will be lost. Obviously, this option should only be used in extreme circumstances.
If you want to run s-Server in the background (as a daemon owned by the default user sqlstream, rather than as a service) you can type:
$ s-Server --daemon &
[1] 8675
The response gives the PID of the process.
This disconnects the s-Server process from your terminal and puts it into the background. s-Server will run until you log out of your server.
When you exit from the Linux server, you will be reminded that you have job(s) running in the background. If you continue, the job will be stopped.
To stop the daemon you need to know its job number or pid.
If you have started any background jobs, you can list them:
$ jobs
[1]+ Running nohup tail -f /var/log/sqlstream/Trace.log.0 2>&1 &
[2]+ Running ....
Once you have the job number, you can signal it using kill - giving the job number preceded by a % sign:
kill %3
Note that if you close your terminal, you lose the connection to these jobs. If you connect again, you won’t see them in a jobs list - but they may still be running.
For more about foreground and background processes and the use of jobs and nohup see this tutorial.
You can get the pid of the s-Server process in one of two ways. The first uses ps:
ps -ef | grep AspenVJdbcServer
To extract only the pid you can extend that:
PID=$(ps -ef | grep java | grep AspenVJdbcServer | awk '{print $2}')
The other option is to use Java’s jps tool to identify the s-Server process. If we run this on a sqlstream/complete docker container we see:
$ $JAVA_HOME/bin/jps
$JAVA_HOME/bin/jps
1280 QuorumPeerMain
1281 Kafka
1145 Main
285 AspenVJdbcServer
7853 Jps
The s-Server PID is 285 (AspenVJdbcServer). Again - assuming there is only one s-Server instance running on the server you can extract the required PID:
PID=$($JAVA_HOME/bin/jps | grep AspenVJdbcServer | cut -d' ' -f1)
Now you know the PID or job number, you can signal the process to stop gracefully (or not). By default kill sends the SIGTERM signal.
Signal name | Signal number | s-Server console command equivalent | Description |
---|---|---|---|
SIGTERM | 15 | !quit | Graceful shutdown with checkpoint if there are no open sessions |
? | !kill | Terminate open sessions and then shutdown with checkpoint | |
SIGINT | 2 | Ctrl-C | Abort shutdown without creating a checkpoint |
SIGKILL | 9 | Force kill the process without creating a checkpoint |
You can use the signal number or name (with or without the SIG prefix), and kill lets you use the -s <signal> switch, or simply use the signal as a switch. Here are some examples:
kill $PID # sends a SIGTERM to the process
kill -15 $PID # the same using the signal number as a switch
kill -s 15 $PID # the same using the -s switch
kill -term $PID # the same using the short name of the signal
kill -s sigterm $PID # the same using the long name of the signal, and the -s switch
kill -sigterm $PID # this is not valid; the -s at the beginning of the switch confuses things