Traditionally, Linux systems typically used SysV init as the initialization daemon, borrowed from older Unix systems. More recently, however, most Linux distributions have standardized on using systemd to handle system initialization. The initialization system can be used to automatically start Synergy services like synd and xfServer (rsynd) when a system boots up. For Linux and Unix distributions of Synergy/DE, we distribute scripts in the synconfig directory to aid in setting up these services on production systems, but these scripts are intended to work with SysV init. While systemd maintains some backward compatibility with SysV init and these scripts may still work for you, you might find it more convenient to set up native systemd services instead. This guide gives a brief overview of how to set up systemd services for Synergy products, as well as some useful commands for monitoring and troubleshooting systemd.
Systemd is used by the latest versions of all Linux distributions officially supported for use with Synergy/DE, so the information in this KB is likely to apply regardless of your distribution. However, these commands have not been tested on all systems (and won\'t work on older versions that used SysV or Upstart instead). So, take these suggestions with a grain of salt, and consult the documentation for your distribution for specific information for your system. Also note that most commands in this KB assume that you have root access, so if any command fails as a normal user, you can try it again with "sudo" or log in as root.
Service files for systemd
Services in systemd are controlled by service unit files, typically located in /etc/systemd/system. To add a new service, create and edit a text file in that location with the .service extension. Here are some example unit files for the Synergy services synlm, synsrv, synxfpl, and synsql.
$ cat /etc/systemd/system/synlm.service
[Unit]
Description=Synergy License Service
[Service]
Type=forking
ExecStart=/install/path/synergyde/lm/synd
ExecStop=/install/path/synergyde/lm/synd -q
[Install]
WantedBy=multi-user.target
$ cat /etc/systemd/system/synsrv.service
[Unit]
Description=Synergy Default xfserver Service
After=network.target synlm.service
[Service]
Type=forking
ExecStart=/install/path/synergyde/dbl/bin/rsynd
ExecStop=/install/path/synergyde/dbl/bin/rsynd -q
[Install]
WantedBy=multi-user.target
$ cat /etc/systemd/system/synxfpl.service
[Unit]
Description=Synergy Default xfserverPlus Service
After=network.target synlm.service
[Service]
Type=forking
ExecStart=/install/path/synergyde/dbl/bin/rsynd -w -p2356 -u username/encodedpassword
ExecStop=/install/path/synergyde/dbl/bin/rsynd -p2356 -q
[Install]
WantedBy=multi-user.target
$ cat /etc/systemd/system/synsql.service
[Unit]
Description=Synergy SQL OpenNet Service
After=network.target synlm.service
[Service]
Type=forking
ExecStart=/install/path/synergyde/connect/synsql
ExecStop=/install/path/synergyde/connect/vtxkill -p1958 localhost
[Install]
WantedBy=multi-user.target
Unit files can be simpler or more complicated than these, but these are a good starting point to get Synergy services to work as expected. You\'ll notice that each unit file shares a common set of (case-sensitive) sections and directives, although some are only used by specific services. Here\'s an explanation for each of the lines:
[Unit]—The first section of the unit file, with general information about the service.
Description—A human-readable description of this service that will show up, e.g., when checking on the status of the service.
After—This directive lists one or more units that should be started before starting the current unit. You could probably omit this without any problems when starting synd. But if you want to start synd and rsynd as separate services, the rsynd service should list the synd service in this directive, e.g. "After=network.target synlm.service".
[Service]—The second section of the file, with information about how to run the service itself.
Type=forking—Describes what type of process is running. Many services consist of a single process that will run for as long as the service is active, in which case they would have a type of "simple". But when you start a Synergy service like synd or rsynd, the process you start only runs long enough to fork into a child process that runs in the background. Likewise, vtxnetd is typically started with the startnet script, which launches the service in the background and then exits. So Synergy services should have a type of "forking", so that systemd doesn\'t get confused when the initial parent processes go away.
ExecStart—The most important part of the service, this line tells systemd what command to use when it starts the service. For License Manager, this should probably be the full path to the installed synd executable, with no command line arguments. For xfServer or xfServerPlus, you can specify the full path to rsynd, along with whatever arguments you want for this particular service, as shown in the xfServerPlus example (synxfpl.service).
Alternatively, you can specify a script here if you want to run something that can\'t be expressed on a single command line (e.g., if you want to run multiple xfServer processes on different ports but control them all with a single systemd service). The synsql.service file for SQL OpenNet shows an example of this:
ExecStart=/install/path/synergyde/connect/synsql
In this case, synsql is a script that sets up the environment for Synergy and runs the startnet script to start vtxnetd:
$ cat /install/path/synergyde/connect/synsql
#!/bin/bash
. /install/path/synergyde/setsde
/install/path/synergyde/connect/startnet
The script in this case specifies the shell to use in its first line. You could also specify the shell as the ExecStart value and pass the script as an argument (see below for an example). If a shell isn\'t specified in the script or in the ExectStart directive, the script may fail to start.
ExecStop—This tells systemd what command to use when it\'s shutting down the service. If you don\'t include this line, it will just send a kill signal to the process, which will probably shut down the service as expected, but the shutdown may not be as graceful and you\'d like. For a graceful shutdown of synd or rsynd, you can just use the path to the executable and add the -q option (along with -p if you\'re shutting down an rsynd service on a non-default port). For SQL OpenNet, you can use a command like "/install/path/vtxkill -p1958 localhost". As with ExecStart, this could also be a script.
[Install]—The final section of the file, which tells systemd what symbolic links to set up so that the service is started at the correct point during system startup.
WantedBy—Tells systemd when this service should be started. The value "multi-user.target" is typical and will start the service during a regular system start up before users log in.
Additional Directives
The Wants, Requires, and Before directives might be useful in addition to the ones mentioned above.
The simple example above shows how the After directive can define a relationship between multiple services. There are other directives in the [Unit] section with similar effects. For instance, the synlm and synsrv files could look like this:
$ cat /etc/systemd/system/synlm.service
[Unit]
Description=Synergy License Service
Before=synsrv.service
Wants=synsrv.service
…
$ cat /etc/systemd/system/synsrv.service
[Unit]
Description=Synergy Default xfserver Service
After=synlm.service
Requires=synlm.service
…
This establishes a closer relationship between the synlm and synsrv services, so that shutting down or starting up synlm will cause synsrv to shut down or start up as well. Likewise, starting the synsrv service will cause the synlm service to start if it isn\'t already running. But it doesn\'t work in the other direction: shutting down synsrv won\'t cause synlm to shut down.
The directives work as follows:
After—When starting services, start the current service after starting the unit(s) listed in this directive. By itself, this directive doesn\'t cause systemd to start any units, so if a listed unit isn\'t running and doesn\'t start up, the current service will fail to start.
Before—When starting services, start the current service before starting the unit(s) listed in this directive. As with After, this directive by itself doesn\'t cause systemd to start any units aside from the current on. So this doesn\'t imply that the listed units will be started after the current one, just that systemd won\'t try to start them before this one if they aren\'t already running. If a listed service is already running, that won\'t prevent the current unit from starting.
Requires—When starting services, start the listed unit(s) alongside this one. This establishes a dependency between the services, so that if a listed service shuts down, the current service will shut down as well. By itself, this directive doesn\'t establish the order in which services will start up.
Wants—When starting services, start the listed unit(s) alongside this one. Unlike Requires, Wants does not establish a dependency between the services, so if a listed service shuts down, the current service will not shut down as well. By itself, this directive doesn\'t establish the order in which services will start up.
In the earlier example, synsrv.service only had an After directive, which caused it to start after synlm, but didn\'t establish a dependency or cause synlm to automatically start up. This was sufficient to get everything to run properly, because both services were started when the system booted up, and xfServer didn\'t start before License Manager was available. Either that approach or the one in this section could work fine, depending on your preferences. But I would caution against using Requires or Wants by itself in Synergy services without also specifying the order with Before or After. Because Requires and Wants start up the listed units without regard to order, adding a directive like "Requires=synlm.service" in an rsynd service without also adding "After=synlm.service" could cause synlm to start up after rsynd, at which point rsynd would already have failed.
Restart—A directive for the [Service] section, Restart tells systemd whether to restart the service if it terminates unexpectedly. The default implied value is "Restart=no", which doesn\'t attempt to restart the service at all. On the opposite extreme is "Restart=always", which will always try to restart the service. This means that if you attempt to manually terminate a Synergy process without using the systemctl utility (e.g., synd -q, rsynd -q, or vtxkill), the process should immediately start up again. Be careful if you choose to use this, as it has the potential to cause unexpected behavior.
User, Umask, Environment, and WorkingDirectory—These directives also belong in the [Service] section, and control how a service runs (the effective user account, initial permissions of created files, environment variables, and working directory, respectively). These aren\'t likely to be relevant when running a Synergy service (with possible exceptions below), but you might want to keep them in mind if you want to run your own program or script as a service.
One place where these could be useful is if you wanted to run SQL OpenNet by launching the startnet script directly, instead of writing a wrapper script that sets up the environment first. For example:
[Service]
Type=forking
Environment="PATH=$PATH:/usr/bin:."
WorkingDirectory=/install/path/synergyde/connect/
ExecStart=/bin/bash -c "/install/path/synergyde/connect/startnet"
ExecStop=/install/path/synergyde/connect/vtxkill -p1958 localhost
This uses the Environment and WorkingDirectory directives. Because the startnet script doesn\'t start by specifying a shell, we have to do that in the ExecCommand. This approach may not have any advantages over the other alternative, but it is a possibility.
Likewise, User could be used to define the persona user for xfServerPlus, e.g.:
[Service]
Type=forking
User=username
ExecStart=/install/path/synergyde/dbl/bin/rsynd -w -p2356
ExecStop=/install/path/synergyde/dbl/bin/rsynd -p2356 -q
But the -u option for rsynd works just as well for that, and makes a simpler unit file.
Installing and Running Services
The systemctl utility is the primary way of interacting with systemd services. It provides several useful commands such as start, stop, status, enable, and disable, with the typical syntax of "systemctl command servicename". The servicename argument matches the name of the .service file (with or without the extension).
One you\'ve created a service file, you can reload the systemd daemon to make sure that it recognizes the new service (you should also do this whenever editing an existing unit file):
systemctl daemon-reload
Then you can start the service to see if it works, e.g.:
systemctl start synlm
You can check to verify that the service is running, both within systemd and from the list of running processes:
$ systemctl status synlm
synlm.service - Synergy License Service
Loaded: loaded (/etc/systemd/system/synlm.service; disabled; vendor preset: enabled)
Active: active (running) since Mon 2023-04-24 22:40:42 UTC; 17s ago
Process: 2832 ExecStart=/ install/path/synergyde/lm/synd (code=exited, status=0/SUCCESS)
Main PID: 2843 (synd)
Tasks: 2 (limit: 986)
Memory: 2.3M
CGroup: /system.slice/synlm.service
└─2843 /install/path/synergyde/lm/synd
Apr 24 22:40:41 hostname systemd[1]: Starting Synergy License Service...
Apr 24 22:40:42 hostname synd[2832]: Synergy/DE (TM)
Apr 24 22:40:42 hostname synd[2832]: Copyright (c) 1997 - 2022
Apr 24 22:40:42 hostname synd[2832]: Synergex International Corporation
Apr 24 22:40:42 hostname synd[2832]: All rights reserved.
Apr 24 22:40:42 hostname synd[2832]: You must purchase a license from Synergex to be authorized to use this
Apr 24 22:40:42 hostname synd[2832]: product. If you have not done so, you may be in violation of United States
Apr 24 22:40:42 hostname synd[2832]:federal copyright law and may be liable for damages to Synergex.
Apr 24 22:40:42 hostname systemd[1]: Started Synergy License Service.
$ ps -ef | grep synd
root 2843 10 22:40 ? 00:00:00 /install/path/synergyde/lm/synd
devadm 28562615 0 22:43 pts/0 00:00:00 grep --color=auto synd
The service is now running, but is not yet enabled. So it will not automatically start the next time the system boots up. To fix this, run the enable command:
systemctl enable synlm
If you run the status command again, the output should now list the service as enabled.
Monitoring systemd
The systemctl status command is the best way to monitor the current status of systemd systems. You can specify a service and shown above, or just run "systemctl status" with no service name to show a tree view of all running services. Unlike many systemctl commends, "status" doesn\'t require root privileges, though running it as a non-root user may omit some journal information.
The journalctl command can shows the logs that are generated by systemd services. This log information includes everything logged to syslog. You can use the -u argument to specify a particular service, or omit it to page through the entire system log. The output from journalctl can be several pages long (typically piped through "less"); to quickly see the most recent information, use the -n option to limit the display to a specified number of lines from the end, or the -r option to display results in reverse order.
The systemd-analyze command can also be useful in analyzing systemd, especially if a service isn\'t starting up or if system startup is taking longer than expected. For instance, "systemd-analyze critical-chain serrvicename " will show the current specified service and a chain of services that it depends on, with the time each of them took to start up. Note that the servicename argument in this case must include the ".service" extension. The "systemd-analyze blame" command sorts services by the time they took to start up.
Command List
For quick reference, here are some examples of commands for managing systemd:
journalctl Shows full syslog
journalctl -b Shows syslog from current boot
journalctl -r Shows syslog in reverse order
journalctl -u servicename Shows syslog for specified service
journalctl -u servicename -n 20 Shows most recent 20 lines for the specified service
systemctl daemon-reload Refresh systemd to reflect changes to .service files
systemctl disable servicename Disable the specified service so it won\'t start at boot
systemctl enable servicename Enable the specified service to start at boot
systemctl restart servicename Stop the specified service and start it again
systemctl start servicename Start the specified service
systemctl status Shows tree view of all running services
systemctl status servicename Shows current status the specified service
systemctl stop servicename Stop the specified service
systemd-analyze Shows statistics for system startup
systemd-analyze blame Shows how long it takes for each service to start up
systemd-analyze critical-chain servicename Shows dependencies and timing of specified service
systemd-analyze plot > filename.svg Export details of system startup to .svg graphic file
Conclusion
This KB article has been an introduction to systemd and the ways you can use it to interact with Synergy. It\'s far from a comprehensive or definitive guide, so you may want to do your own research and testing to find the best practices for your situation. But the techniques show here are ones that we\'ve found to work fairly well with Synergy. Hopefully this will be helpful in deploying Synergy on modern Linux systems.
References
https://www.howtogeek.com/devops/how-to-add-your-own-services-to-systemd-for-easier-management/
https://www.howtogeek.com/687970/how-to-run-a-linux-program-at-startup-with-systemd/
https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
https://serverfault.com/questions/413397/how-to-set-environment-variable-in-systemd-service
800.366.3472
Get Support
Documentation
Synergex.com
