Systemd setup: Difference between revisions
(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:
- This is a very simplified example, please lookup for more detailed references in case you have something more complex.
[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
As you can see in the service example above, we're telling systemd:
Description
: what's the name of the serviceAfter
: when systemd should start the program (eg after the OS network is up and running)Type
,Restart
,User
: hopefully, self-explanatoryWorkingDirectory
: tells systemd we want to run our ExecStart command from a specific directoryWantedBy
: I still don't understand what's this exactly, it seems necessary to let systemd know you want this service available
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