Le programme Boblight ne s'exécute pas en arrière-plan. Il n'y a pas de différence notable entre l'exécution
sudo boblightd
et
sudo boblightd&
Comment puis-je résoudre ce problème qui empêche la console de bloquer d'autres entrées?
pi@raspberrypi ~/boblight/boblightd-for-raspberry-master $ sudo boblightd
Boblightd 2.0 (optimized version for raspberry) (c) 2013 Speedy1985 and Heven)
(InitLog) start of log /root/.boblight/boblightd.log
(PrintFlags) starting boblightd
(CConfig::LoadConfigFromFile) opening /etc/boblight.conf
(CConfig::CheckConfig) checking config lines
(CConfig::CheckConfig) config lines valid
(CConfig::BuildConfig) building config
(CConfig::BuildConfig) built config successfully
(main) starting devices
(CClientsHandler::Process) opening listening TcpSocket on *:19333
(CDevice::Process) ambilight: starting with output "/dev/spidev0.0"
(CDevice::Process) ambilight: setting up
(CDevice::Process) ambilight: setup succeeded
pi@raspberrypi ~/boblight/boblightd-for-raspberry-master $ sudo boblightd&
[1] 2289
pi@raspberrypi ~/boblight/boblightd-for-raspberry-master $
Boblightd 2.0 (optimized version for raspberry) (c) 2013 Speedy1985 and Heven)
(InitLog) start of log /root/.boblight/boblightd.log
(PrintFlags) starting boblightd
(CConfig::LoadConfigFromFile) opening /etc/boblight.conf
(CConfig::CheckConfig) checking config lines
(CConfig::CheckConfig) config lines valid
(CConfig::BuildConfig) building config
(CConfig::BuildConfig) built config successfully
(main) starting devices
(CClientsHandler::Process) opening listening TcpSocket on *:19333
(CDevice::Process) ambilight: starting with output "/dev/spidev0.0"
(CDevice::Process) ambilight: setting up
(CDevice::Process) ambilight: setup succeeded
shell
sudo
background-process
user2534685
la source
la source
sudo boblightd > /dev/null 2>&1 &
dmenu
. C'est simple et ça marche assez bien.Réponses:
La
[1] 2289
commande après votre arrière-plan montre que cela a fonctionné et a été effectivement mise en arrière-plan.Mais la sortie de votre commande ira toujours au terminal, sauf si vous redirigez. Voici la manière complète de le faire:
Si vous voulez que stdout et stderr aillent dans le même fichier:
Et, bien sûr, si vous ne vous souciez pas de la sortie de l'un ou des deux flux, vous pouvez envoyer à
/dev/null
au lieu d'un nom de fichier.(cet exemple supprime la sortie standard, mais conserve stderr, juste au cas où quelque chose se passe mal.)
MISE À JOUR
Ce qui précède n'est basé sur aucune connaissance de ce qu'est boblightd. Je vois dans une autre réponse qu'il a un mode démon, qui devrait donc être utilisé à la place dans ce cas.
BTW, ce qui précède suppose
sudo
qu'il ne vous sera pas demandé de mot de passe et que vous ne fermerez pas la fenêtre du terminal. Pour le premier, personnellement, j'utilise normalementsudo bash
alors, taperaisboblightd >std.txt 2>err.txt &
. Une autre façon consiste àsudo ls
exécuter une commande inoffensive pour vous assurer que l'accès est mis en cache.Pour ce dernier,
nohup
c'est la commande magique pour vous assurer qu'elle continue de fonctionner même après que vous ayez quitté le bâtiment. Il irait après lesudo
et avant la commande réelle. Par exemplesudo nohup boblightd >std.txt 2>err.txt &
. Ousudo bash
alorsnohup boblightd >std.txt 2>err.txt &
, alorsexit
(pour quitter le shell racine).la source
sudo
essayez de demander le mot de passe, il échouera car les processus d'arrière-plan ne peuvent pas lire STDIN.Je pense que vous pouvez utiliser la commande nohup comme ceci:
cela mettra la sortie de votre commande dans le fichier nohup.out dans le répertoire courant.
Vous pouvez également utiliser la commande d'écran comme ceci: créez d'abord un écran:
puis exécutez votre commande:
Pour enregistrer l'écran et revenir au terminal, tapez Ctrl+AD( Ctrl+Aest l'indice pour
screen
lequel vous voulez faire quelque chose, Dpuis "d" se retire de la session sans l'arrêter).restaurez votre écran:
la source
Vous devrez rediriger stdout et stderr vers autre chose que leurs valeurs par défaut pour les masquer. Le commentaire de @ devnull montre comment procéder. C’est une première étape.
Si vous utilisez simplement
&
pour détacher votre programme, il sera automatiquement tué lorsque vous vous déconnecterez. Ce n'est probablement pas ce que vous voulez. Vous devrez utiliser lanohup
commande pour éviter cela:nohup sudo boblightd > boblight.out 2> boblight.err < /dev/null &
Notez que
sudo
cela demandera probablement un mot de passe: il n'en obtiendra pas, et vous ne remarquerez pas qu'il vous le demande, car chaque sortie / entrée est redirigée. Vous avez de toute façon différentes solutions pour y parvenir:sudo
commande avant,sudo
enregistrera votre mot de passe. C'est la façon rapide et simple.&
, donnezsudo
le mot de passe, puis envoyez le processus en arrière-plan avec CTRL + Z.la source
sudo
? Commentsudo
obtient-il son mot de passe lorsque vous l'exécuteznohup
?&
, de donnersudo
le mot de passe, puis d'envoyer le processus en arrière-plan avecctrl + z
. Vous pouvez également configurersudo
pour ne pas demander le mot de passe pour cet utilisateur spécifique et ce couple exécutable.sudo bash
, je lance lanohup
commande depuis l'intérieur du nouveau shell.&
que le fond, le processus sera tué à la déconnexion. Ce n'est que si bash est tué avec un SIGHUP qu'il va alors SIGHUP votre programme. Mais la déconnexion ne provoque pas de SIGHUP. Si vous tapezlogout
ou utilisez CTRL + D, bash se ferme et laisse le processus en cours. SIGHUP est envoyé lorsque vous fermez l'émulateur de terminal dans une interface graphique.Boblightd
Dans le cas de boblightd, la sortie envoyée à stderr est déjà capturée dans son fichier journal (par défaut ~ / .boblight / boblightd.log ), donc cela n'a pas besoin d'être capturé et peut être supprimé. De plus, boblight ne se charge pas par défaut mais peut être fait en incluant le -f dans la commande.
Je vous suggère d'essayer ce qui suit:
(détails de la documentation du projet )
Plus généralement
Les processus démarrés à partir du shell se termineront à la fin du shell. Comme d'autres l'ont souligné Ctrl-Zlors de l'exécution d'un processus au premier plan, le contrôle revient au shell. Cependant, le processus est placé dans un état arrêté à ce stade. La
bg
commande sera nécessaire pour relancer le processus mais en arrière-plan. Il nécessite soit un identifiant de processus ou le numéro de travail (comme les numéros de travail habituels sont préfixés par un%), donc en utilisant votre deuxième exemple, vous émettriez soitou
Le processus s'exécutera maintenant en arrière-plan mais est toujours attaché au shell. Le lien vers le shell peut être rompu à l'aide de la
disown
commande, ce qui évite la confusion avec nohup / sudo. Comme avecbg
,disown
ne nécessite que l'ID de processus ou le numéro de travailpar exemple
Vous pouvez maintenant quitter le shell en toute sécurité comme si vous aviez exécuté le processus avec la
nohup
commandela source
Étant donné que la réponse est déjà assez bien exposée dans les commentaires. J'ai pensé qu'il serait bon de poster un peu d'explication à ce sujet comme une réponse réelle.
La voie à suivre est donc:
sudo boblightd > /dev/null 2>&1 &
Il y a 3 parties importantes ici. Le plus important est
&
en fin de ligne. Cela empêche le shell d'attendre la fin de la commande avant de redonner le contrôle. Il supprime également l'entrée standard du clavier. Cela met le travail en arrière-plan.Mais cela laisserait toujours la sortie dans la console. Pour éviter cela, un
>
symbole redirige la sortie standard (vers/dev/null
dans ce cas).À ce stade, vous pouvez toujours obtenir la sortie de la commande appelée get to screen. Ce serait l'erreur standard. Enfin, il y a la
2>&1
magie. Cela redirige la sortie du flux d'erreur standard vers la sortie standard.2
et1
proviennent de descripteurs de fichiers standard.0
seraitstdin
,1
- stdout,2
- stderr.Vous pouvez rediriger la sortie vers un fichier si vous en avez besoin.
Il existe des commandes conçues pour interagir avec les travaux en arrière-plan.
jobs
etfg
.Vous pouvez également jouer avec des solutions plus avancées telles que la
screen
commande si nécessaire.la source