Barrier: Impossible d'exécuter le client barrière Linux au démarrage à l'aide de systemd

Créé le 1 mai 2019  ·  5Commentaires  ·  Source: debauchee/barrier

Systèmes d'exploitation

Serveur : Windows 10 version 1709 (version du système d'exploitation 16299.1087)
Client : Ubuntu 18.04 (bureau GNOME 3)

Version barrière

Serveur : 2.2.0
Client : 2.2.0

Étapes pour reproduire le bogue

  1. L'objectif est de rendre le client Linux barrière au démarrage pendant le démarrage
  2. Configurer le script de service systemd [script de service joint ci-dessous]
  3. sudo systemctl start barrier.service
  4. La barrière parvient à démarrer mais renvoie l'erreur : " ATTENTION : écran secondaire indisponible : impossible d'ouvrir l'écran "
  5. Échec de la connexion au serveur

Autre info

  • Quand le problème a-t-il commencé à se produire ?
    Lorsque vous essayez de configurer le service systemd.
  • Y a-t-il un moyen de le contourner?
    Non, si vous voulez une barrière au démarrage avant de vous connecter à l'utilisateur.
  • Ce bogue vous empêche-t-il d'utiliser entièrement Barrier ?
    Non

Mettez tout ce que vous pouvez penser ici.

Mon script de service sous /etc/systemd/system/barrier.service

[Unit]
Description=Start Barrier client during boot

[Service]
Type=simple
Restart=always
RestartSec=2
ExecStart=/usr/bin/barrierc -f --debug DEBUG2 --log /tmp/barrier-service.log --name ubuntu-Desktop [<server-info>]:24800

[Install]
WantedBy=multi-user.target

Journaux :

tail -f /tmp/barrier-service.log 

[2019-04-30T22:26:50] DEBUG: XOpenDisplay(":0.0")
[2019-04-30T22:26:50] WARNING: secondary screen unavailable: unable to open screen
[2019-04-30T22:26:50] DEBUG: retry in 60 seconds
[2019-04-30T22:27:50] DEBUG: XOpenDisplay(":0.0")
[2019-04-30T22:27:50] WARNING: secondary screen unavailable: unable to open screen
[2019-04-30T22:27:50] DEBUG: retry in 60 seconds

Commentaire le plus utile

Notez que cela fonctionne si je lance la barrière nativement (c'est-à-dire pas sur ssh), mais cela va à l'encontre de tout l'objectif de la barrière car je dois brancher un deuxième clavier et une deuxième souris pour le faire

Tous les 5 commentaires

Si je devais deviner, je dirais qu'il démarre trop tôt et que Barrier ne corrige pas cela. L'utilisation de votre gestionnaire d'affichage pour démarrer et arrêter Barrier peut fonctionner. Ou au lieu d'exécuter Barrier en tant que root, vous pouvez vous connecter automatiquement. Choisissez votre poison.

Voir aussi #179 et #185

Merci @noisyshape , je vais lire les références que vous avez mentionnées. Je crois que c'est un problème Linux plutôt que Barrier. Je le ferme maintenant.

Cela m'arrive aussi, sauf que j'essaie de lancer une barrière sur ssh. Voilà ce que j'obtiens :

user<strong i="6">@xenon</strong>:~$ /snap/barrier-kvm/2/bin/barrierc -f --no-tray --debug DEBUG --name xenon [192.168.1.192]:24800
[2020-01-11T15:09:06] DEBUG: XOpenDisplay(":0.0")
Invalid MIT-MAGIC-COOKIE-1 key[2020-01-11T15:09:06] WARNING: secondary screen unavailable: unable to open screen
[2020-01-11T15:09:06] DEBUG: retry in 60 seconds
[2020-01-11T15:09:06] DEBUG: event queue is ready
[2020-01-11T15:10:06] DEBUG: XOpenDisplay(":0.0")
Invalid MIT-MAGIC-COOKIE-1 key[2020-01-11T15:10:06] WARNING: secondary screen unavailable: unable to open screen
[2020-01-11T15:10:06] DEBUG: retry in 60 seconds
[2020-01-11T15:11:06] DEBUG: XOpenDisplay(":0.0")
Invalid MIT-MAGIC-COOKIE-1 key[2020-01-11T15:11:06] WARNING: secondary screen unavailable: unable to open screen
[2020-01-11T15:11:06] DEBUG: retry in 60 seconds

J'utilise Xubuntu 18.04.3

Notez que cela fonctionne si je lance la barrière nativement (c'est-à-dire pas sur ssh), mais cela va à l'encontre de tout l'objectif de la barrière car je dois brancher un deuxième clavier et une deuxième souris pour le faire

@RPGillespie6 Je ne sais pas si c'est le même problème que vous, mais j'ai contourné cela simplement en commençant barriers sur ssh en utilisant --display :1 .

Cette page vous a été utile?
0 / 5 - 0 notes