Custom systemd Unit and Unit File: Difference between revisions
Line 61: | Line 61: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
<font color=darkkhaki>Is this really necessary? Why exactly? At this point the file is completely unknown to the system, it as not enabled.</font> | <font color=darkkhaki>Is this really necessary? Why exactly? At this point the file is completely unknown to the system, it as not enabled.</font> | ||
For more details on <code>daemon-reload</code> see: {{Internal|Systemd_Concepts# | For more details on <code>daemon-reload</code> see: {{Internal|Systemd_Concepts#Daemon_Reload|systemd Concepts | Daemon Reload}} | ||
=Enable at Boot= | =Enable at Boot= |
Revision as of 23:18, 19 August 2023
Internal
Overview
This article describes the procedure to configure an arbitrary service minecraft
to be managed by systemd
. It includes the creation of corresponding unit file and systemd
configuration to start and stop the service automatically at boot, respectively shutdown.
Create the Unit File
Create the /etc/systemd/system/minecraft.service
unit file. As root:
touch /etc/systemd/system/minecraft.service
chmod 644 /etc/systemd/system/minecraft.service
For more details on the location of the unit files, see:
Configure the Unit File
Process Started and Stopped by Auxiliary Scripts
This is common for Java programs, /home/minecraft/minecraft-server/minecraft
is a wrapper script that starts the JVM and puts in background like this:
java -server -jar ... > $(dirname $0)/logs/stdout-and-sterr.log 2>&1 &
The unit file configuration is similar to:
[Unit]
Description=Minecraft service
After=network.target
[Service]
Type=oneshot
ExecStart=/home/minecraft/minecraft-server/minecraft start
ExecStop=/home/minecraft/minecraft-server/minecraft stop
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Also see:
Daemon Process that Forks and Creates Its Own PID File
[Unit]
Description=MyService
After=network.target
[Service]
ExecStart=/opt/myservice/bin/myservice
Type=forking
PIDFile=/var/run/myservice.pid
[Install]
WantedBy=multi-user.target
Also see:
Notify systemd of the Existence of the New Unit File
systemctl daemon-reload
Is this really necessary? Why exactly? At this point the file is completely unknown to the system, it as not enabled.
For more details on daemon-reload
see:
Enable at Boot
systemctl enable myservice.service
Exercise the Service
systemctl start myservice systemctl status hello systemctl restart hello systemctl stop hello