Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**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.**

Un des programmes que j'ai écrits et que j'utilise presque chaque jour est quelque chose que j'ai appelé « media-tracker ». C'est une appli Ruby on Rails qui me permet de d'ajouter/de pister un film (de cinéma ou de DVD) et les publications de jeux. Dernièrement, j'ai aussi commencé à suivre les épisodes actuels des émissions sur les services de streaming (Netflix, Crunchroll, Amazon Prime Video) du fait de la fréquence à laquelle je commence une émission, j'en regarde un bout, puis je m'aperçois qu'elle a été retirée du service de streaming. De cette façon, je peux détecter où je me suis arrêté si l'émission apparaît quelque part ailleurs ou si je l'achète en DVD. Pour faire court, je démarre cette appli manuellement dans Tmux chaque fois que je me connecte. J'en ai eu finalement marre et, à la place, j'ai créé un petit service systemd pour lancer le script au démarrage.

**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.**

Notes

Cet article se concentrera sur l'installation et le fonctionnement d'une appli Rails via systemd. Si vous utilisez quelque chose de différent, les grandes lignes seront les mêmes, mais vous aurez peut-être des variables d'environnement en plus à ajuster.

Toutes les commandes ont été lancées sur un système ArchLinux. Si votre distribution a un format différent (c'est-à-dire systemctl <service> <command>), restez sur le format de votre distribution. Si vous hésitez, utilisez les commandes que je liste et voyez quelles erreurs apparaissent.

**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.**

Faire le paramétrage

D'abord, vous voudrez bien noter où se trouvent vos fichiers et tous les chemins que vous devez connaître (tel que $GEM_HOME et la partie adéquate de votre $PATH). Vous pouvez trouver ces informations en lançant simplement ce qui suit dans votre terminal préféré :

echo $PATH
echo $GEM_HOME

C'est important, car vous devrez dire à Systemd à quelles valeurs paramétrer ces variables, sinon les commandes planteront ou ne seront simplement pas trouvées.

**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.**

À décider - Service utilisateur ou service système ?

Les systèmes les plus modernes ont paramétré systemd pour tourner à la fois dans une version système et dans une version spécifique à l'utilisateur. Elles sont séparées (et elles surveillent des dossiers différents). L'approche est similaire dans les deux cas, mais voici les principales différences :

1. Les services de systemd à l'échelle du système, quand ils sont autorisés, tournent au démarrage. Les services basés sur l'utilisateur démarreront à la connexion.
2. Les services basés sur l'utilisateur ne peuvent être configurés pour fonctionner aussi en tant qu'autre utilisateur (par exemple, si vous voulez lancer Apache comme un utilisateur « html », ou similaire). Vous devrez alors utiliser la version à l'échelle du système.

Réfléchissez-y et prenez votre décision. Puis, sautez à la section pertinente.

**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.**

Service à l'échelle du système

Le fichier media-tracker.service que j'ai créé ressemble au code présenté ci-dessous.

Comme vous pouvez le voir, il y a quelques points importants dans ce fichier. D'abord, je paramètre Type à « simple », ce qui signifie que je m'attends à ce que la commande ExecStart tourne dès que le service est actif. Il y a d'autres types (par exemple, si une commande démarre puis se termine, comme un script bash). Cependant, dans la plupart des cas, j'imagine que « simple » sera suffisant. Puis je règle l'utilisateur avec mon nom d'utilisateur, pour m'assurer que le service peut accéder à mes fichiers d'applis et aux Gems installés.

En parlant de Gems, j'ai besoin de configurer les variables d'environnement pour pointer sur les chemins de mes répertoires .gem ; autrement, le service ne trouvera pas les commandes correctes. La plupart des articles que j'ai vus à ce sujet affirment que « bash -lc » chargera le profil shell de l'utilisateur (et par conséquent les variables), mais ça ne semble pas être le cas dans ArchLinux. Si vous voulez tester pour voir si ces lignes sont nécessaires sur votre machine, il suffit de les supprimer, puis de vérifier la sortie de votre service par 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.**

Enfin, je paramètre WorkingDirectory (répertoire de travail - le chemin vers mes fichiers d'applis), puis ExecStart pour tourner conjointement avec le serveur rails.

Les autres options sont assez compréhensibles par elles-mêmes, ou n'ont pas besoin d'être modifiées.

Copiez/déplacez le fichier dans /etc/systemd/system/  et appelez-le <quelque-chose>.service (la partie <quelque-chose> peut être ce que vous voulez). Une fois que le fichier est là, vous pouvez le démarrer/l'activer avec les commandes suivantes :

sudo systemctl start media-tracker.service

sudo systemctl enable media-tracker.service

Pour arrêter/désactiver le service, il suffit de remplacer start ou enable par le mot stop ou disable. De même, vous pouvez lancer status pour obtenir le code de sortie et l'état actuel du 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.**

Si vous faites des modifications dans le fichier du service, vous pourriez recevoir un avertissement disant que les fichiers doivent être rechargés. Pour ce faire, lancez :

sudo systemctl daemon-reload

Pour déboguer les problèmes, vous pouvez utiliser la commande suivante :

journalctl -u media-tracker

Remplacez media-tracker par le nom de fichier que vous avez choisi.

Fichier de service spécifique pour un utilisateur

Le fichier que j'ai créé pour un service spécifique à un utilisateur ressemble au code présenté ci-dessus.

La principale différence entre lui et le fichier service à l'échelle du système est l'absence de la valeur « User » (Utilisateur).

**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.**

Comme je l'ai dit dans la section au-dessus (pour tous ceux qui sont passés directement à cette section) :
1. Paramétrez les variables d'environnement dont vous aurez besoin pour ce service.
2. Réglez l'option WorkingDirectory sur le dossier du projet.
3. Le /bin/bash -lc devrait lancer le shell bash comme shell à la connexion, mais, sous ArchLinux, ça ne semble pas remplir les variables d'environnement ; c'est pourquoi le point 1 existe.
4. Les autres options dans le fichier se comprennent d'elles-mêmes ou, dans le cas de WantedBy, ne devrait pas nécessiter d'ajustement. 

**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.**

Faire tourner le service

Le lancement du service spécifique à un utilisateur est aussi facile que :

systemctl --user start media-tracker

Notez l'absence de sudo et l'argument « --user ». Les autres commandes sont toutes sur le même format - stop, enable, disable et status. Remplacez simplement le mot start par l'option que vous souhaitez.

**Debug

In case your service fails to run, you can run journalctl --user -u media-tracker to get the output of your service.**

Débogage

Au cas où votre service refuse de fonctionner, vous pouvez lancer journalctl --user -u media-tracker pour obtenir la sortie de votre 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.**

Conclusion

J'espère que cet article est utile à tous ceux qui, comme moi, ont un programme personnalisé qu'ils veulent lancer à chaque connexion ou au démarrage. Il semble que beaucoup d'articles sur des sujets comme ceux de cette série se concentrent sur les services à l'échelle du système ; c'est la raison pour laquelle j'ai inclus aussi les instructions pour les services spécfiques à un utilisateur. Si vous rencontrez des problèmes, ou si vous avez des améliorations à m'offrir, n'hésitez pas à m'envoyer un mail à lswest34+fcm@gmail.com. De même, si vous avez des demandes pour des articles, dirigez-les vers la même adresse mail.


**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.