Ceci est une ancienne révision du document !
One of the programs I’ve written that I use pretty much every day is something I call “media-tracker”. It’s a Ruby on Rails app that allows me to add/track movie (cinema and DVD) and game releases. Lately, I’ve also started tracking current episodes of shows from streaming services (Netflix, Crunchroll, Amazon Prime Video) due to the frequency with which I start a show, watch a chunk of it, and then notice it’s been removed from the streaming service. This way I can pick up where I’ve left off if the show pops up somewhere else or I buy a DVD of it. Long story short - I start this app in Tmux manually every time I log in. I’ve finally gotten tired of this, and instead created a small systemd service to run the script on boot.
Notes This article will focus on getting a Rails app up and running through systemd. If you’re using something different, the broad strokes will be the same, but you may need to adjust more environment variables. All commands have been run on an ArchLinux system. If your distribution has a different format (ie, systemctl <service> <command>), then stick to your distribution’s format. If you’re unsure, then use the commands I list here and see what errors occur.
Getting set up First, you want to make note of where your program’s files are, and any paths you need to know (such as the $GEM_HOME and the relevant section of your $PATH). You can find these by simply running the following in your terminal of choice: echo $PATH echo $GEM_HOME This is important, as you’ll need to tell Systemd what to set these variables to, otherwise commands will fail or simply not be found.
Decide - user or system service? Most modern systems have systemd set up to be run as both system, and a user-specific version. They are separate (and have separate folders they watch). The approach is similar for either one, but here are the main differences: 1. System-wide systemd services, when enabled, run on boot. User-based services will on run on login. 2.User-based services also can’t be configured to run as another user (for example if you want to run Apache as an ‘html’ user or similar). Then you’ll need to use the system-wide version. Think about it and make your decision. Then skip ahead to the relevant section.
System-wide service The media-tracker.service file I created looks like the code shown below. As you can see, there are a few important aspects to this file. First, I set Type to “simple”, which means the ExecStart command is expected to run just while the service is alive. There are other types (for example if a command runs and then quits, like a bash script). For most cases, I imagine “simple” will be sufficient, though. I then set the user to my username, to ensure the service has access to my app files and the installed Gems. Speaking of Gems, I needed to configure the environment variables to point to my .gem directory paths, otherwise the service failed to find the correct commands. Most articles I saw on this topic claimed that bash -lc would load the user’s shell profile (and therefore the variables), but that didn’t seem to be the case in ArchLinux. If you want to test to see if these lines are required on your machine, just delete them and check the output of your service through journalctl.
Lastly, I set the WorkingDirectory (path to my app files), and then ExecStart to run bundle exec rails server. The other options are relatively self-explanatory, or shouldn’t need to be changed. Copy/place the file in /etc/systemd/system/ and call it <something>.service (the <something> part can be anything you want). Once the file is there, you can start/enable it with the following commands: sudo systemctl start media-tracker.service sudo systemctl enable media-tracker.service To stop/disable the service, just replace start or enable with the word stop or disable. Similarly, you can run status to get the exit code and current status of the service.
If you make changes to the service file, you may get a warning that the files need to be reloaded. To do that, run: sudo systemctl daemon-reload To debug issues, you can use the following command: journalctl -u media-tracker Replace media-tracker with the file name you chose. User-specific service file The file I created for a user-specific service looks like the code shown above. The main difference between this and the system-wide service file is the missing “User” value.
As I said in the section above (for anyone jumping directly to this section): 1. Set the environment variables you’ll need for this service. 2. Set the WorkingDirectory option to the project folder. 3. The /bin/bash -lc should run the bash shell as a login shell, but, under ArchLinux, this doesn’t seem to fill the environment variables, hence why point 1 exists. 4. The other options in the file are self-explanatory, or, in the case of WantedBy, shouldn’t need to be adjusted.
Running the service Running a user-specific service is as easy as: systemctl –user start media-tracker Note the lack of sudo, and the “–user” argument. The other commands are all of the same format - stop, enable, disable, and status. Just replace the word “start” with whatever option you need.
Debug In case your service fails to run, you can run journalctl –user -u media-tracker to get the output of your service.
Conclusion I hope this article is useful for anyone who, like me, has a custom program they want to run on every login or boot. It seems like a lot of articles on topics like these focus on system-wide services, which is why I also included instructions for user-specific services. If you run into issues, or have improvements to offer me, feel free to send me an email at lswest34+fcm@gmail.com. Similarly, if you have any article requests, direct them to the same email address.
Further Reading https://wiki.archlinux.org/index.php/systemd - The ArchWiki article on Systemd https://wiki.archlinux.org/index.php/Systemd/User - The ArchWiki article on user-based Systemd.
Pour aller plus loin
https://wiki.archlinux.org/index.php/systemd - L'article d'ArchWiki sur Systemd
https://wiki.archlinux.org/index.php/Systemd/User - L'article d'ArchWiki sur Systemd basé sur l'utilisateur.