Como terminar o xvfb-run corretamente

5

Para realizar alguns testes de unidade JavaScript com karma dentro de um contêiner docker (baseado no ubuntu 14.04) iniciando o firefox no container usando um karma-script-launcher com xvfb-run . O script de início é assim:

#!/bin/bash
set -o errexit 

# nasty workaround as xvfb-run doesn't cleanup properly...
trap "pkill -f /usr/lib/firefox/firefox" EXIT

xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' firefox $1

Iniciar o navegador e executar os testes de unidade funciona muito bem. Depois de executar os testes, o karma encerra a instância do navegador gerada - no meu caso, o script que lançou o firefox sobre xvfb-run.

No script acima, você pode ver que registrei um trap para matar o firefox iniciado ao sair do meu script. Isso funciona, mas o script não é um bom cidadão, pois encerra todas as instâncias do firefox que estão sendo executadas atualmente, em vez de apenas terminar a instância lançada pelo script. Primeiro tentei matar o processo xfvb-run , mas matar este processo não tem efeito sobre o subprocesso lançado pelo script xvfb-run ...

Se eu iniciar o Firefox sobre xvfb-run manualmente, há vários processos gerados:

root@1d7a5988e521:/data# xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' firefox &
[1] 348
root@1d7a5988e521:/data# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 bash
  348 ?        S      0:00 /bin/sh /usr/bin/xvfb-run --auto-servernum --server-args=-screen 0, 1024x768x16 firefox
  360 ?        S      0:00 Xvfb :99 -screen 0, 1024x768x16 -nolisten tcp -auth /tmp/xvfb-run.bgMEuq/Xauthority
  361 ?        Sl     0:00 /usr/lib/firefox/firefox
  378 ?        S      0:00 dbus-launch --autolaunch bcf665e095759bae9fc1929b57455cad --binary-syntax --close-stderr
  379 ?        Ss     0:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
  388 ?        S      0:00 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
  414 ?        R+     0:00 ps ax
root@1d7a5988e521:/data#

Se eu agora matar o processo xvfb-run (PID 348), apenas este processo será finalizado, deixando os outros processos em execução. Se eu matar o processo do firefox (PID 361), o script xvfb-run terminará corretamente e também matará os outros processos. Mas do meu script eu só conheço o PID do processo xvfb-run ...

Durante minha pesquisa, deparei com relatório de bugs bastante antigo para xvfb-run que ainda parece ser válido apesar do status do bug ser corrigido em 2012.

Existe alguma maneira educada de terminar o processo xvfb-run para que os outros processos sejam limpos corretamente?

Eu já perguntei isso no Stack Overflow, mas não tenho resposta até agora. Talvez seja um pouco OT para Stack Overflow, mas melhor localizado aqui?!

    
por dpr 24.06.2016 / 11:23

2 respostas

3

Parece que você está usando apenas xvfb-run para sua funcionalidade --auto-servernum .

Como @meuh apontou: que a lógica é realmente simples :

# Copyright (C) 2005 The T2 SDE Project
# Copyright (C) XXXX - 2005 Debian
# GNU GPLv2
find_free_servernum() {
    # Sadly, the "local" keyword is not POSIX.  Leave the next line commented in
    # the hope Debian Policy eventually changes to allow it in /bin/sh scripts
    # anyway.
    #local i

    i=$SERVERNUM
    while [ -f /tmp/.X$i-lock ]; do
        i=$(($i + 1))
    done
    echo $i
}

Com essa função definida: você pode tentar uma invocação como esta em vez de usar xvfb-run :

Xvfb :$(find_free_servernum) -screen 0, 1024x768x16 firefox $1 &
THE_PID=$!
# kill Xvfb whenever you feel like it
kill -15 $THE_PID

Com xvfb-run removido: não precisamos mais nos preocupar com como matar xvfb-run .

    
por 22.09.2016 / 14:16
0

Minha solução foi iniciar o xvfb no script entrypoint do Docker:

Xvfb :0 -screen 0 1024x768x24 &

Você pode colocar essa mesma linha também em algum tipo de script de início do sistema operacional (por exemplo, .bashrc ), caso não esteja usando o Docker.

Em seguida, em outro script, eu exportei a exibição e chamei a função real que queria usar

export DISPLAY=:0
firefox $1
    
por 01.05.2018 / 12:18

Tags