Linux / Comando jobs: listar trabalhos e PIDs no Bash atual

jobs mostra os trabalhos em segundo plano e os trabalhos parados que o Bash atual acompanha. Ele consulta a tabela de trabalhos desse shell, não um inventário de todos os processos do sistema. Use jobs -l para acrescentar os identificadores de processo, os PIDs.

Um trabalho pode conter um comando simples ou vários processos de uma cadeia de comandos conectados por pipes. Seu número no shell, como %1, é diferente de um PID. Um novo Bash ou outro terminal não recebe automaticamente a mesma tabela de trabalhos.

Sintaxe e contexto do Bash

jobs [opções] [especificador_de_trabalho]

Confira type jobs e help jobs no shell usado. No Bash, jobs é um comando interno. A documentação dos comandos de controle de trabalhos do Bash descreve suas opções e a diferença entre consultar, retomar e sinalizar trabalhos.

Execute os três exemplos curtos a seguir na mesma sessão de Bash, um depois do outro. Abrir um novo bash -c para cada linha não mantém a tabela do shell anterior.

Iniciar e listar um trabalho em segundo plano

O & no final inicia o comando de forma assíncrona, permitindo que o shell receba outro comando enquanto sleep aguarda:

sleep 120 &

Em uma sessão interativa, o Bash pode informar o número do trabalho e seu PID. Os valores variam; não copie um número de outro terminal. Essa espera termina naturalmente depois de 120 segundos.

No mesmo Bash, consulte a tabela antes de a espera terminar:

jobs

Leia o número entre colchetes, o estado e o comando registrado. Running indica um trabalho em execução, em oposição a um trabalho parado; não significa que ele esteja consumindo CPU continuamente. Um sleep pode aparecer como Running enquanto aguarda.

Para acrescentar os PIDs à listagem:

jobs -l

O exemplo com sleep é um comando simples. Em um pipeline, um trabalho pode corresponder a vários processos; não suponha que o número do trabalho, um PID individual e o identificador do grupo de processos sejam intercambiáveis.

Comparar a tabela atual com um Bash novo

O exemplo completo abaixo exige Bash e sleep. Execute-o sem set -e. Ele cria uma espera de 60 segundos, mostra diferentes consultas, abre outro Bash apenas para consultar a tabela nova e encerra somente o filho cujo PID guardou em $!. Os parênteses limitam as variáveis e a sequência a um sub-shell.

(
  sleep 60 &
  demo_pid=$!
  printf '%s\n' 'Tabela do Bash que iniciou o teste:'
  jobs -l
  printf '%s\n' 'Identificadores apresentados por jobs -p:'
  jobs -p
  printf '%s\n' 'Trabalhos em execução:'
  jobs -r
  printf '%s\n' 'Trabalhos parados:'
  jobs -s
  printf '%s\n' 'Tabela de um Bash novo:'
  bash --noprofile --norc -c 'jobs -l'
  kill -s TERM "$demo_pid"
  signal_status=$?
  wait "$demo_pid"
  wait_status=$?
  printf 'envio=%s wait=%s\n' "$signal_status" "$wait_status"
  printf '%s\n' 'Tabela após recolher o filho:'
  jobs -l
)

Antes do término, jobs -l deve apresentar o sleep e jobs -r deve incluí-lo. jobs -s pode ficar vazio, pois essa prática não para o trabalho. A consulta no Bash novo não mostra o trabalho criado pelo shell anterior. Depois do SIGTERM e do wait, a listagem final já não deve apresentar aquele filho.

Em uma execução com Bash 5.3.9 do Git para Windows, essas diferenças foram observadas com o modo monitor desligado: a tabela de origem mostrou o sleep, o Bash novo mostrou uma tabela vazia e a consulta após wait ficou vazia. O resumo foi envio=0 wait=143. O teste usou somente o filho criado para a prática; não verificou Ctrl+Z, fg, bg nem grupos de processos numa sessão interativa de Linux.

Ler número, PID e estado

Esta linha é uma ilustração de uma consulta jobs -l, com número e PID variáveis; o espaçamento e o idioma do estado dependem do ambiente:

[1]+ 12345 Running  sleep 60 &

[1] é o número do trabalho naquele shell; 12345 é o PID mostrado neste exemplo simples. O sinal + identifica o trabalho considerado atual pelo Bash; - identifica o anterior quando houver essa marca. Eles não indicam maior ou menor prioridade de CPU. As regras básicas de controle de trabalhos do Bash explicam essas referências.

Running, Stopped e Done distinguem execução, parada e conclusão. Um trabalho parado pode ser retomado, enquanto um concluído já terminou. Na verificação disponível, um filho true que terminou naturalmente apareceu como Done na primeira consulta jobs -l e não apareceu na segunda. Portanto, a tabela não é um histórico permanente: o Bash remove entradas concluídas após informar seu estado.

Opções de consulta

-n lista trabalhos cujo estado mudou desde a última notificação. Um especificador como jobs %1 restringe a consulta a um trabalho existente na tabela atual; o número precisa ser conferido naquela sessão. Já a forma jobs -x executa o comando recebido depois de substituir especificadores por identificadores; não é apenas outra forma de imprimir a lista.

Lista vazia, retomada e término

Se jobs não mostrar nada, confirme se está no mesmo Bash, se o trabalho já terminou e se você abriu um shell novo. Para examinar processos além dessa tabela, use uma consulta adequada de ps. A consulta padrão de ps também tem seus próprios critérios; não equivale automaticamente à lista de todos os processos.

Em um Bash interativo com controle de trabalhos ativo, Ctrl+Z normalmente para o trabalho em primeiro plano; bg pode retomá-lo em segundo plano e fg pode trazê-lo ao primeiro plano. Essas operações dependem do terminal e do controle de trabalhos. A consulta da tabela e o controle interativo não devem ser confundidos: o teste não interativo acima mostrou jobs funcionando mesmo com monitor desligado.

Para encerrar uma espera de teste antes do prazo, confira seu PID e use o procedimento de envio e verificação de SIGTERM com kill. A forma com um trabalho, como kill %1, só deve ser usada no contexto apropriado depois de conferir qual trabalho %1 representa. O exemplo completo guarda $! para evitar depender de um número de trabalho fixo e usa wait para recolher o estado do próprio filho.

Iniciar com & não transforma a tarefa em serviço nem garante que ela continuará depois de fechar o terminal. Se precisar dessa continuidade, escolha uma solução apropriada, como uma sessão persistente ou um gerenciador de serviços. O guia de nohup trata a proteção contra desligamento de terminal e seus limites; isso é uma questão diferente de visualizar jobs.

Pergunta frequente

Por que jobs está vazio quando ps ainda mostra processos?

Jobs consulta somente a tabela acompanhada pelo Bash atual. Processos de outro shell, trabalhos já retirados da tabela e processos iniciados por serviços podem aparecer numa consulta de ps sem serem trabalhos desse Bash. Confira a sessão e os critérios antes de interpretar uma lista vazia como ausência de processos no sistema.