Running atomic-server as a service (auto-restart, start on boot) using `systemd`
Since I wanted to start atomic-server whenever it crashes because of my memory issue #270, I created a systemd setup. Might be useful to others.
Also, I'm considering to add similar functionality to the server itself. Maybe add a setup-service or daemon subcommand that installs something like this.
How to make atomic-server a service
Create a service:
vim /etc/sytemd/system/atomic.service
Paste this:
[Unit]
Description=Atomic-Server
#After=network.targetdd
StartLimitIntervalSec=0[Service]
[Service]
Type=simple
Restart=always
RestartSec=1
User=root
ExecStart=/root/atomic-server
WorkingDirectory=/root/
EnvironmentFil=/root/.env
[Install]
WantedBy=multi-user.target
# start service
systemctl run atomic
# check status
systemctl status atomic
# restart
systemctl restart atomic
# logs
journalctl -u atomic.service
# logs, since one hour, follow
journalctl -u atomic.service --since "1 hour ago" -f
Nice. But wrong place to put it: Only the project author will generally read tickets in an issue tracker, whereas others (developers of related projects and users) will generally only write to the issue tracker.
Simplest way to (more likely, but not ensured) reach sysadmins is to mention this info in README.md.
More elegantly, however, is to include a file examples/atomic-server.service with the content and mention more briefly its existence in README.md.
Maybe there is more formal support in Rust crates to declare example files, or maybe even system config files, but lacking that, I recommend using directory examples as described above.
Your systemd service unit file contains several typos, and is tailored for a service executed as root which is generally frowned upon.
I suggest taking inspiration from my file at https://salsa.debian.org/debian/atomic-data-rust/-/blob/debian/latest/debian/atomic-server.service if you decide to include a systemd service unit file as an example file with the project.
@jonassmedegaard agreed that an example in the repo is the way to go, as soon as one is good enough. I can't access the link you provided, can you directly post the .service here or (even better) open a PR?
I can't access the link you provided
That's odd! That repo should certainly be public readable, and I just tested logging out from that Gitlab instance and could still read it.
What error message do you get, or in what other way does it fail for you?
can you directly post the .service here, or (even better) open a PR?
I won't push PRs to Github due to their problematic terms of service automatically granting them certain licensing implicitly by simply using their service.
So I would much prefer that you can access the Debian repo, as I might very well update data there.
There were some 500's coming from the gitlab instance, but it looks like that's resolved now. Anyways, looks good!