Systemd setup: Difference between revisions

From Hackers & Designers
(Created page with "{{Article |MainNavigation=No }}")
 
(Init)
 
Line 1: Line 1:
Whether that's good or bad, we're using <code>systemd</code> to manage "services", eg. running a website / web-app through some standard commands.
What this allows is to:
* run a specific program,
* check its status,
* restart it at will,
* tell systemd to start it automatically if we reboot the server,
* tell systemd to restart it automatically if the program crashes for some reasons,
* etc
=== List services ===
You can run this command to list all services managed by systemd:<syntaxhighlight lang="bash">
systemctl list-units --type=service
</syntaxhighlight>This shows everything, and not only the services added by a specific user. As of now (as far as I know, which is little), we're not creating services under a specific user but under root (?), so there might be way to better filter out this list.
=== Add a service ===
To add a new service, follow these steps:
* create a new file under <code>/etc/system/systemd</code>: <code>sudo touch /etc/system/systemd/<service-name>.service</code>
* add the following as a starting point:
* <syntaxhighlight lang="bash">
[Unit]
Description=<service-name>
After=network.target
[Service]
Type=simple
Restart=always
RestartSec=1
User=<user you want the web-app to run under>
WorkingDirectory=<path/to/web-app/>
ExecStart=<command to use to run the web-app>
[Install]
WantedBy=multi-user.target
</syntaxhighlight>This is a very simplified example, please lookup for more detailed references in case you have something more complex.
As you can see in the service example above, we're telling systemd:
* <code>Description</code>: what's the name of the service
* <code>After</code>: when systemd should start the program (eg after the OS network is up and running)
* <code>Type</code>, <code>Restart</code>, <code>User</code>: hopefully, self-explanatory
* <code>WorkingDirectory</code>: tells systemd we want to run our ExecStart command from a specific directory
* <code>WantedBy</code>: I still don't understand what's this exactly, it seems necessary to let systemd know you want this service available
{{Article
{{Article
|MainNavigation=No
|MainNavigation=No
}}
}}
After you created a new service file (or after you updated an existing one), you want to run this command to "refresh" systemd, so that it can see your new service:<syntaxhighlight lang="shell">
sudo systemctl daemon-reload
</syntaxhighlight>Afterwards:
* enable the service (to make it start at system boot / reboot): <code>sudo systemctl enable <service-name>.service</code>
* start the service: <code>sudo systemctl start <service-name>.service</code>
* check its status: <code>sudo systemctl status <service-name>.service</code>
* restart it (in case you modified something in the web-app for instance): <code>sudo systemctl restart <service-name>.service</code>
* stop it: <code>sudo systemctl stop <service-name>.service</code>
* disable the service: <code>sudo systemctl disable <service-name>.service</code>
=== Debugging ===
While running <code>sudo systemctl status <service-name>.service</code> gives you an idea if the service is running fine or not, you don't get much more than that. Depending on your web-app setup (for instance), you might have setup a logging system.
In that case, you can also use the <code>journalctl</code> to access it, by doing:<syntaxhighlight lang="shell">
sudo journalctl -e -u <service-name>.service
</syntaxhighlight>
* <code>-e</code>: stands for "end", and it shows you the end of the logging file, eg the latest entries in the log
* <code>-u</code>: stands for "unit" (I believe), and lets you filter out which logs to display, by setting the service name you want to inspect
[[Category:Infrastructure]]

Latest revision as of 15:43, 2 March 2023

Whether that's good or bad, we're using systemd to manage "services", eg. running a website / web-app through some standard commands.

What this allows is to:

  • run a specific program,
  • check its status,
  • restart it at will,
  • tell systemd to start it automatically if we reboot the server,
  • tell systemd to restart it automatically if the program crashes for some reasons,
  • etc

List services

You can run this command to list all services managed by systemd:

systemctl list-units --type=service

This shows everything, and not only the services added by a specific user. As of now (as far as I know, which is little), we're not creating services under a specific user but under root (?), so there might be way to better filter out this list.

Add a service

To add a new service, follow these steps:

  • create a new file under /etc/system/systemd: sudo touch /etc/system/systemd/<service-name>.service
  • add the following as a starting point:
  • [Unit]
    Description=<service-name>
    After=network.target
    
    [Service]
    Type=simple
    Restart=always
    RestartSec=1
    User=<user you want the web-app to run under>
    
    WorkingDirectory=<path/to/web-app/>
    ExecStart=<command to use to run the web-app>
    
    [Install]
    WantedBy=multi-user.target
    
    This is a very simplified example, please lookup for more detailed references in case you have something more complex.

As you can see in the service example above, we're telling systemd:

  • Description: what's the name of the service
  • After: when systemd should start the program (eg after the OS network is up and running)
  • Type, Restart, User: hopefully, self-explanatory
  • WorkingDirectory: tells systemd we want to run our ExecStart command from a specific directory
  • WantedBy: I still don't understand what's this exactly, it seems necessary to let systemd know you want this service available
MainNavigation No

After you created a new service file (or after you updated an existing one), you want to run this command to "refresh" systemd, so that it can see your new service:

sudo systemctl daemon-reload

Afterwards:

  • enable the service (to make it start at system boot / reboot): sudo systemctl enable <service-name>.service
  • start the service: sudo systemctl start <service-name>.service
  • check its status: sudo systemctl status <service-name>.service
  • restart it (in case you modified something in the web-app for instance): sudo systemctl restart <service-name>.service
  • stop it: sudo systemctl stop <service-name>.service
  • disable the service: sudo systemctl disable <service-name>.service

Debugging

While running sudo systemctl status <service-name>.service gives you an idea if the service is running fine or not, you don't get much more than that. Depending on your web-app setup (for instance), you might have setup a logging system.

In that case, you can also use the journalctl to access it, by doing:

sudo journalctl -e -u <service-name>.service
  • -e: stands for "end", and it shows you the end of the logging file, eg the latest entries in the log
  • -u: stands for "unit" (I believe), and lets you filter out which logs to display, by setting the service name you want to inspect