Linux servers are designed to run at all times; rather than manually starting important programs and leaving them in a
tmux session, you should add them to
systemd as a service that will automatically start at startup and restart if errors occur.
Working with Systemd And Services
Systemd stores configuration for services in two locations. The first is
/ lib / systemd / system / where you will find configuration for many services on your system. Most software installations install services here. The second is
/ etc / systemd / system / which overrides the directory
/ lib / systemd and is usually used to place user-created services in. There is also
/ etc / systemd / users / who run services for individual logged in users, such as retrieving email.
Many of these services do not run all the time as nginx or MySQL would do. You can print a list of services currently in use with swith:
Services with a "+" symbol are run and services with a "-" symbol are currently stopped. You can see more detailed information with:
service status nginx
Since services are running in the background, they do not log their output to your console but log out instead in the system diary. The "Status" command displays the last lines of this journal, but you can read it directly with:
journalctl -fn 50 -u nginx
This command prints the last 50 log entries (
- n ) from the nginx service (
-u ). It is configured to print everything and start at the bottom, after new log entries when created (
Of course, many applications will still write most things to their access or error logs, so be sure to check those as well. The diary keeps track of things that are logged in directly to the console, which can be useful for troubleshooting your own services.
Simple Service Setup
Systemd is used for many things in Linux; each object handled is called a device and has a corresponding "device file" that defines what it is. These can be simple services like nginx or MySQL, but they can also be things like mounting points, drives, outlets and lots of other things under the hood, all handled by systemd. Devices can also be targets, which are used to control when other services will be running (ie after the network is initiated).
For this use case, you probably just want to configure your application as a basic service. To do this, you must create a new device file that you want to place in
/ etc / systemd / system / and name it with an
touch / etc / systemd /system/myapp.serviceebrit19659006??Unit files have some different sections, but overall it looks like this:[Unit] Description = Example Service After = network.target StartLimitIntervalSec = 0 [Service] Type = simple Restart = always RestartSec = 1 User = serviceuser ExecStartPre = ExecStart = / path / to / executable [options] ExecStartPost ExecStop = ExecReload = [Install] WantedBy = multi-user.target
First up, section
[Unit]that defines a bunch of device metadata. The
After =directive can be used to delay device activation until another device is started, such as
networkor another service, such as
mysql.serviceThis does not " That makes it a heavy dependency on that service, but you can do it with
Want =directive. This section also configures the maximum number of times the device will try start before systemd leaves completely; since you probably want it to continue trying, you can set this to 0 to disable this behavior.
Next is the section
[Service]specific to service device files, this is where you configure the Exec options.
Userswill run the service as a specific user, you can set this to your personal user account, root or a custom service account, just make sure you use recommended that each user has enough privileges to do its job.
There are a few different directives here to specify programs to run.
ExecStartPrewill run first, so you can make all the necessary settings before the service actually starts.
ExecStartis the most important executable.
ExecStartPostis then run, and
ExecStopis run when the service is turned off.
ExecReloadis a special directive and is used when you call "reload" instead of restarting. This allows you to perform a reload of configuration for driving provided that your application has capacity.
Finally, the section
[Install]that defines more behavior related to how the systemd handles the device. This is most often used to specify the
WantedBy =directive, which is used to tell systemd when to start your service and creates symlinks between targets and their dependent devices. If you are unsure which target you want to use,
multi-user.targetwill run services on startup when most everything is loaded.
Overall, the configuration is quite simple and everything you really need to do is put into your executable as an argument in the section
[Service]. Once your service is created, you must reload systemctl daemon to update with your changes:sudo systemctl daemon-reload
And enable it (which runs it at startup, per device configuration):  sudo systemctl enable myapp
And then start the service:sudo service myapp start
The service should now be run in the background, and you can check
journalctlto see its results. If it expires,
systemdwill automatically restart, and it should be run at startup along with other services on your system.
If you need to restart your service, you can use:sudo service myapp restart
Which will execute the
ExecStop =directive, turn off the device, and then restart it.