Démarrer le relais automatiquement

oar start fait tourner le relais en arrière-plan jusqu’à ce que vous l’arrêtiez ou que la machine redémarre. Pour que le relais revienne de lui-même, installez le démarrage automatique : oar service install Ajouté en 0.9.9 le met en place sous Linux et Windows. Ajouté en 0.9.15 oar autostart choisit l’un ou l’autre mode Windows, à l’ouverture de session ou au démarrage, et oar setup le demande sous Windows. Ensuite, vous n’avez plus besoin d’un terminal ouvert, et sur un hôte sans interface, vous n’avez pas besoin de vous connecter.

Le service fait tourner le même relais que oar start : la même config, le même dossier de données et le même dossier de journaux. Rien ne change pour vos conversations. Ajouté en 0.9.14 Sous Windows, c’est vrai aussi pour les deux modes de démarrage automatique ; avant 0.9.14, ils gardaient les données dans le paquet installé (voir Dossier de données des entrées Windows).

Les commandes #

oar service install
oar service status
oar service remove

oar service status est la commande par défaut quand vous ne donnez aucun mot. Ces commandes sont destinées aux installations globales ; dans un checkout git, elles le disent et ne font rien. oar seul ouvre un menu dont l’entrée Install or remove the service (Installer ou supprimer le service) fait la même chose. oar setup --start et l’installateur macOS et Linux installent le service Linux pour vous là où une session utilisateur systemd existe.

oar service install a besoin d’une config : lancez d’abord oar setup.

Ajouté en 0.9.15 oar autostart nomme le mode au lieu d’un service :

oar autostart signin    # Windows: at sign-in
oar autostart boot      # Windows: at boot, before anyone signs in
oar autostart off
oar autostart status    # the default when you give no word

Sous Windows, c’est la commande pour les deux modes, avec les mêmes règles que le réglage Autostart (Windows) (Démarrage automatique sous Windows) dans Settings (Réglages). Sous Linux, c’est oar service : signin et boot lancent tous deux oar service install, off lance oar service remove et status lance oar service status. Sous macOS, elle affiche Autostart is not supported on macOS yet. Start the relay with: oar start. Dans un checkout git, elle indique qu’elle est destinée aux installations globales. signin et boot ont besoin d’une config ; off et status, non.

Linux : le service utilisateur systemd #

Ajouté en 0.9.8

Le service s’appelle oar. oar service install écrit son fichier d’unité dans ~/.config/systemd/user/oar.service, l’active et le démarre. Il lance aussi loginctl enable-linger pour votre utilisateur. Le lingering maintient vos services utilisateur actifs quand personne n’est connecté : le relais revient donc après un redémarrage et continue de tourner après votre déconnexion. Rien ici n’a besoin de sudo. Si le lingering ne peut pas être activé, la commande le dit et donne la ligne à lancer vous-même, car sans lui, le relais s’arrête quand vous vous déconnectez :

loginctl enable-linger "$USER"

L’unité démarre le relais avec le Node.js qui a lancé la commande et le redémarre après un plantage (Restart=on-failure, au bout de 5 secondes). Ajouté en 0.9.14 Elle ne redémarre pas un relais qui s’est arrêté avec le code de sortie 78 (RestartPreventExitStatus=78) : le relais utilise ce code quand il ne peut pas tourner sur ses données, par exemple quand un autre relais détient son verrou (voir Si ça ne marche pas). Une unité écrite par une version antérieure n’a pas cette ligne tant que vous ne relancez pas oar service install. L’unité reprend le PATH du shell qui a lancé oar service install, plus ~/.local/bin et le dossier de ce Node.js, car un service utilisateur systemd démarre sinon avec un PATH minimal. Les sessions du relais trouvent les CLI des fournisseurs et node grâce à lui. Après une modification de votre PATH, relancez oar service install puis oar restart : install réécrit l’unité mais ne redémarre pas un service qui tourne déjà.

Si un relais que vous avez démarré à la main tourne, install l’arrête d’abord pour que le service puisse prendre le port. Si ce relais est occupé et ne s’arrête pas tout de suite, le service est installé et prend la main à la prochaine connexion, ou quand vous lancez oar start une fois le relais arrêté.

start, stop et restart #

Une fois le service installé, oar start, oar stop et oar restart passent par systemd.

État et journaux #

systemctl --user status oar

indique si le service tourne. L’unité ne redirige pas la sortie du relais : systemd la garde donc dans le journal, et journalctl --user -u oar la lit.

L’unité définit aussi le dossier de journaux du relais sur le dossier logs du dossier d’état d’OAR (~/.oar/logs par défaut). Le relais y garde une copie de sa console dans relay-console.log, et chaque worker de session écrit un worker-<session>.log. oar doctor affiche le dossier d’état sous lequel ils se trouvent.

Windows #

Ajouté en 0.9.2

Windows a deux modes de démarrage automatique. Les deux font tourner le même relais avec la même config.

Le réglage se trouve dans ⚙️ Settings → General (Réglages → Général), sous le libellé Autostart (Windows). Il n’apparaît que sur un relais Windows et propose trois choix :

Off
At sign-in — visible terminal after you log on
At system startup — headless, no logon needed

Ajouté en 0.9.15 Dans un terminal sous Windows, oar setup demande le mode en dernière question, avec le mode en vigueur comme valeur par défaut :

Autostart: 1 = at sign-in, 2 = at boot, before anyone signs in (one administrator prompt), 3 = off [3]:

Enter conserve le mode tel quel. oar setup --autostart signin|boot|off le règle sans poser la question. Si la tâche de démarrage ne peut pas être lue, setup ne pose pas la question. Quand le changement n’aboutit pas, setup écrit quand même la config, affiche The config is written; the autostart step did not go through (see above). et se termine avec le code 1.

Chaque changement retire l’entrée de l’autre mode, mais seulement si OAR l’a générée (voir Entrées qu’OAR n’a pas créées).

At sign-in #

Choisissez At sign-in, ou lancez oar autostart signin ou oar service install. Tous écrivent la même entrée, oar-web-relay.cmd dans votre dossier Démarrage : les commandes et le réglage sont donc d’accord. oar autostart off, oar service remove ou Off (Désactivé) la suppriment. Aucun d’eux ne démarre le relais tout de suite : le relais démarre à votre prochaine ouverture de session, ou maintenant avec oar start. Passer du démarrage système à l’ouverture de session demande la confirmation administrateur qui retire la tâche de démarrage.

At system startup #

Choisissez At system startup, ou lancez oar autostart boot. Enregistrer une tâche de démarrage demande des droits d’administrateur, et le relais tourne sans eux : Windows demande donc une confirmation administrateur ; seul l’appel à schtasks est élevé. L’invite n’apparaît que sur le bureau du PC lui-même. oar autostart affiche Confirm the administrator prompt to register the boot task … et attend. Depuis un navigateur sur un autre appareil, Settings affiche Confirm the admin prompt on the PC… (Confirmez l’invite administrateur sur le PC…). Les deux attendent jusqu’à deux minutes ; une invite restée sans réponse d’ici là compte comme un échec. La tâche tourne sous votre utilisateur sans mot de passe enregistré. Les fichiers locaux et le tunnel fonctionnent normalement ; la tâche n’a pas d’identifiants pour les partages réseau.

Revenir à Off ou At sign-in (oar autostart off, oar autostart signin) demande la même confirmation pour retirer la tâche. Ajouté en 0.9.15 Le réglage n’active l’entrée d’ouverture de session qu’une fois cette invite confirmée et la tâche supprimée.

Ajouté en 0.9.15 Une invite refusée ne change rien : Nothing changed: the administrator prompt was declined. Le mode précédent reste tel quel, et aucun fichier n’est laissé derrière. Si le changement lui-même échoue après l’invite, il remet les tâches qu’il a supprimées à partir de leurs copies (<task>.task.xml.bak dans le dossier OAR, %APPDATA%\oar), garde les copies et signale l’échec. Si l’invite a été confirmée mais que la tâche ne peut pas être relue ensuite, OAR le dit, nomme les copies et n’annule rien. Dans l’interface web, un échec affiche le problème et une commande à lancer plutôt depuis un PowerShell élevé.

Ajouté en 0.9.15 Le mode au démarrage s’active et se désactive avec une espace, une apostrophe ou des caractères non ASCII dans le chemin de votre profil, par exemple C:\Users\Jürgen. Les versions antérieures échouaient dans ce cas, ou prenaient la propre tâche d’OAR pour une tâche faite à la main.

La tâche de démarrage lance un script lanceur généré par OAR, oar-web-relay-launcher.cmd dans le dossier OAR. Ajouté en 0.9.11 Le lanceur ajoute le dossier de Node.js à la fin du PATH. Le relais démarre ses workers sur son propre Node.js par chemin complet : ils démarrent donc même si le PATH de la tâche ne contient pas node (Le processus de l’agent).

Quand un lanceur généré manque ou provient d’une version antérieure, Settings indique la différence au lieu de signaler un échec, et choisir à nouveau At system startup (ou oar autostart boot) le régénère. Quand un changement du réglage échoue, Settings affiche la raison donnée par le relais. Si une entrée d’ouverture de session existe à côté de la tâche de démarrage, le réglage avertit qu’elle peut démarrer le relais deux fois ; choisissez à nouveau At system startup pour faire le ménage.

oar service ne fait que signaler ce mode. Tant que la tâche de démarrage est en place, oar service install et oar service remove refusent et vous renvoient vers oar autostart signin|off ou Settings ; oar service status affiche on, at boot (scheduled task).

État Ajouté en 0.9.15 #

oar autostart status affiche le mode, puis chaque entrée présente, et si OAR l’a générée :

[oar] Autostart: at boot, before anyone signs in (scheduled task)
[oar]   scheduled task \oar-relay (generated by OAR)
[oar]   C:\Users\dev\AppData\Roaming\oar\oar-web-relay-launcher.cmd (generated by OAR)

Le mode est at sign-in (Startup folder), at boot, before anyone signs in (scheduled task), off ou unknown, the boot task could not be read (<reason>). Une entrée faite à la main s’affiche <path> (hand-made), et une entrée laissée par une autre installation d’OAR <path> (hand-made: it starts the OAR install in <folder>). Quand il y en a une, une dernière ligne indique comment la remplacer.

Entrées qu’OAR n’a pas créées Ajouté en 0.9.15 #

OAR ne modifie que les entrées de démarrage automatique exactement telles qu’une version d’OAR les a générées pour cette installation, dans l’interface web comme dans oar autostart. Toute autre entrée est hand-made et n’est jamais supprimée ni écrasée :

• une entrée Démarrage que vous avez modifiée, ou celle d’une autre installation ou config d’OAR ;
• la tâche de démarrage quand elle diffère de celle qu’OAR enregistre par le compte, le niveau d’exécution, son unique action, son unique déclencheur au démarrage ou ses paramètres ;
• un lanceur que vous avez modifié ;
• une tâche nommée oar-relay créée par quelqu’un d’autre, et la tâche de démarrage d’avant le changement de nom.

Tant qu’une entrée faite à la main resterait à côté du nouveau mode, ou serait remplacée par lui, un changement ne modifie rien et nomme l’entrée :

[oar] Nothing changed: OAR does not delete or overwrite an autostart entry it did not make. Remove it yourself, or replace it keeping a copy: oar autostart boot --replace.
[oar] Left as it is: C:\Users\dev\AppData\Roaming\oar\oar-web-relay-launcher.cmd (hand-made).

L’interface web affiche le même message. Une entrée faite à la main du mode que vous choisissez sert ce mode et reste (Left as it is: …). Pour remplacer les entrées faites à la main par celles d’OAR, lancez le changement avec --replace :

oar autostart boot --replace

Il garde d’abord une copie de chaque entrée, sous la forme <name>.bak dans le dossier OAR (%APPDATA%\oar) : celle du lanceur à côté de lui, le XML exporté d’une tâche sous la forme <task>.task.xml.bak, que schtasks /create /xml sait reprendre, et celle d’une entrée Démarrage là aussi, car Windows ouvrirait à l’ouverture de session une copie laissée dans le dossier Démarrage. Une copie antérieure n’est jamais écrasée : la suivante est .bak-2. Seul --replace remplace une entrée faite à la main.

Une tâche de démarrage qu’OAR ne peut pas lire, par exemple une tâche qui enregistre le mot de passe d’un autre compte et répond Access is denied (Accès refusé), n’est jamais considérée comme absente. L’état indique unknown, the boot task could not be read (<reason>), et chaque changement, --replace compris, s’arrête avec Nothing changed: the boot task could not be read (<reason>).

Attendre TEMP et le lecteur des données Ajouté en 0.9.14 #

Les deux modes attendent avant de démarrer le relais : jusqu’à 5 minutes au total pour le dossier %TEMP% et pour le lecteur du dossier de données, par exemple un disque RAM ou un lecteur qu’un script de démarrage monte plus tard. Avant 0.9.14, le lanceur du démarrage système attendait 2 minutes %TEMP% seulement, et l’entrée d’ouverture de session pas du tout. Un dossier de données sur un partage réseau n’est pas attendu. Un TEMP ou TMP défini avec des guillemets ("D:\My Temp"), ou qui désigne un dossier inexistant, est corrigé pour le relais : les guillemets sont retirés, ou il utilise votre propre dossier temporaire.

Quand l’attente arrive à son terme, une ligne nomme ce qui manque encore et le relais démarre quand même :

[<date> <time>] Still missing after 300 s: data drive "R:\"; starting the relay anyway.

La ligne va dans oar-web-relay-launcher.log à côté du lanceur du démarrage système, ou dans oar-web-relay.log dans le dossier OAR (%APPDATA%\oar) pour l’entrée d’ouverture de session. Un relais dont le dossier de données ne peut toujours pas être créé s’arrête alors avec une ligne qui nomme le dossier, et le code de sortie 78, au lieu d’une trace d’erreur.

Dossier de données des entrées Windows Ajouté en 0.9.14 #

Les deux entrées démarrent le relais sur la config, le dossier de données et le dossier de journaux qu’utilise oar start : %APPDATA%\oar\config.json, %APPDATA%\oar\data et %APPDATA%\oar\logs sur une installation globale. Avant 0.9.14, elles ne définissaient que le fichier de config : un relais qu’elles démarraient gardait donc sa base de données, ses fichiers envoyés et ses journaux dans server\data, server\uploads et server\logs à l’intérieur du paquet installé : d’autres conversations qu’avec oar start, et perdues à la mise à jour suivante. Mettez à jour depuis ces versions comme l’indique la note de mise à niveau.

Le relais met à jour de lui-même une entrée ou un lanceur généré par OAR (à partir de 0.9.0, ainsi que l’ancien copilot-remote-web-relay.cmd d’avant le changement de nom) à son premier démarrage après la mise à jour, sans confirmation administrateur. Une entrée que vous avez modifiée, une entrée qui pointe vers un autre fichier de config et une entrée d’un relais démarré sur ses propres dossiers de données sont laissées telles quelles. Ajouté en 0.9.15 Elles comptent comme faites à la main : oar autostart <mode> --replace les remplace en gardant une copie (voir Entrées qu’OAR n’a pas créées). Réécrire un lanceur pendant que le relais qu’il a démarré tourne encore ne pose pas de problème. Les lanceurs passent la console en UTF-8 : un dossier utilisateur dont le nom contient des caractères non ASCII garde ainsi ses chemins intacts.

macOS #

Le service n’est pas encore disponible sous macOS. oar service le dit et indique oar start. Après un redémarrage, lancez oar start pour redémarrer le relais. L’installateur le démarre en arrière-plan.

WSL #

Le service Linux a besoin d’une session utilisateur systemd. Une distribution WSL n’en a une que si systemd est activé. Sinon, oar service install s’arrête avec une indication : définissez systemd=true sous [boot] dans /etc/wsl.conf, puis redémarrez la distribution depuis Windows avec wsl --terminate <distro>. D’ici là, utilisez oar start. Il en va de même pour un conteneur ou tout Linux sans session utilisateur systemd.

Mises à jour #

oar update demande au relais en cours d’exécution de redémarrer de lui-même, ce qu’il fait une fois sa queue inactive. C’est vrai aussi avec le service Linux : la mise à jour ne passe pas par systemd, elle n’interrompt donc pas les turns. Voir Redémarrages et reprise. Le service et les entrées de démarrage automatique lancent le paquet installé : ils font donc tourner la nouvelle version après ce redémarrage. Mettre à jour le paquet ne touche jamais à la config ni aux données. Ajouté en 0.9.14 La seule exception est la mise à jour vers 0.9.14 depuis un relais Windows en démarrage automatique, dont les données étaient dans le paquet : voir la note de mise à niveau.

Par plateforme #

Si ça ne marche pas #

D’autres problèmes de démarrage sont traités dans Premier lancement. Pour installer OAR au départ, voir Installation.