soju/contrib/soju.service

[Unit]
Description=soju IRC bouncer service
Documentation=https://soju.im/
Documentation=man:soju(1) man:sojuctl(1)
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=soju
Group=soju
DynamicUser=yes
StateDirectory=soju
ConfigurationDirectory=soju
RuntimeDirectory=soju
ExecStart=/usr/bin/soju
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
add an example systemd service file The service file will run `/usr/bin/soju --config /etc/soju/config`. By default it'll run as a dynamically created `soju` user and group (DynamicUser=yes), and it will run in a constrained environment[1], only having write access to /var/lib/soju and /run/soju If the admin creates a static `soju` user and group, those static uid/gid will be used, with the same service constraints. This can be useful to share the static `soju` group with other services, so they can access the soju logs and database even if the service is not running (or before it's running). The procedure for the initial user and database scaffold still works normally, when run as `root`: ``` mkdir /var/lib/soju/ sojudb -config /etc/soju/config create-user myname -admin ``` NOTE: systemd will automatically change the ownership of files in /var/lib/soju/ when the service is started. `sojuctl` will work for root, or with `sudo -u soju`, just normally. References: - [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#DynamicUser= 2023-03-20 16:09:23 +00:00			`[Unit]`
			`Description=soju IRC bouncer service`
			`Documentation=https://soju.im/`
			`Documentation=man:soju(1) man:sojuctl(1)`
			`Wants=network-online.target`
			`After=network-online.target`

			`[Service]`
			`Type=simple`
			`User=soju`
			`Group=soju`
			`DynamicUser=yes`
			`StateDirectory=soju`
			`ConfigurationDirectory=soju`
			`RuntimeDirectory=soju`
			`ExecStart=/usr/bin/soju`
			`ExecReload=/bin/kill -HUP $MAINPID`
			`Restart=on-failure`

			`[Install]`
			`WantedBy=multi-user.target`