Ottieni in modo elegante l'elenco dei processi discendenti

Vorrei ottenere un elenco di tutti i processi da cui discendono (ad es. Bambini, nipoti, ecc.) $pid. Questo è il modo più semplice con cui mi sono inventato:

pstree -p $pid | tr "\n" " " |sed "s/[^0-9]/ /g" |sed "s/\s\s*/ /g"

Esiste un comando o un modo più semplice per ottenere l'elenco completo di tutti i processi discendenti?

Quanto segue è in qualche modo più semplice e presenta l'ulteriore vantaggio di ignorare i numeri nei nomi dei comandi:

pstree -p $pid | grep -o '([0-9]\+)' | grep -o '[0-9]\+'

O con Perl:

pstree -p $pid | perl -ne 'print "$1\n" while /\((\d+)\)/g'

Stiamo cercando numeri tra parentesi in modo da non dare, ad esempio, 2 come processo figlio quando ci imbattiamo gif2png(3012). Ma se il nome del comando contiene un numero tra parentesi, tutte le scommesse sono disattivate. C'è solo finora l'elaborazione del testo che può portarti.

Quindi penso anche che i gruppi di processi siano la strada da percorrere. Se desideri che un processo venga eseguito nel suo gruppo di processi, puoi usare lo strumento 'pgrphack' dal pacchetto Debian 'daemontools':

pgrphack my_command args

Oppure potresti rivolgerti di nuovo a Perl:

perl -e 'setpgid or die; exec { $ARGV[0] } @ARGV;' my_command args

L'unica avvertenza qui è che i gruppi di processi non si annidano, quindi se alcuni processi stanno creando i propri gruppi di processi, i suoi sottoprocessi non saranno più nel gruppo creato.

descendent_pids() {
    pids=$(pgrep -P $1)
    echo $pids
    for pid in $pids; do
        descendent_pids $pid
    done
}

La versione più corta che ho trovato che si occupa anche correttamente di comandi come pop3d:

pstree -p $pid | perl -ne 's/\((\d+)\)/print " $1"/ge'

Si occupa torto se si dispone di comandi che hanno nomi strani come: my(23)prog.

C'è anche il problema della correttezza. L'analisi ingenua dell'output di pstreeè problematica per diversi motivi:

• pstree visualizza i PID e gli ID dei thread (i nomi sono mostrati tra parentesi graffe)
• un nome di comando potrebbe contenere parentesi graffe, numeri tra parentesi che rendono impossibile l'analisi affidabile

Se hai Python e il psutilpacchetto installato, puoi utilizzare questo frammento per elencare tutti i processi discendenti:

pid=2235; python3 -c "import psutil
for c in psutil.Process($pid).children(True):
  print(c.pid)"

(Il pacchetto psutil è ad esempio installato come dipendenza del tracercomando che è disponibile su Fedora / CentOS.)

In alternativa, è possibile eseguire una prima traversata dell'albero di processo in una shell bourne:

ps=2235; while [ "$ps" ]; do echo $ps; ps=$(echo $ps | xargs -n1 pgrep -P); \
  done | tail -n +2 | tr " " "\n"

Per calcolare la chiusura transitiva di un pid, la parte di coda può essere omessa.

Nota che quanto sopra non usa la ricorsione e funziona anche in ksh-88.

Su Linux, è possibile eliminare la pgrepchiamata e invece leggere le informazioni da /proc:

ps=2235; while [ "$ps" ]; do echo $ps ; \
  ps=$(for p in $ps; do cat /proc/$p/task/$p/children; done); done \
  | tr " " "\n"' | tail -n +2

Questo è più efficiente perché salviamo un fork / exec per ogni PID e facciamo pgrepqualche lavoro aggiuntivo in ogni chiamata.

Questa versione di Linux richiede solo / proc e ps. È adattato dall'ultimo pezzo dell'eccellente risposta di @ maxschlepzig . Questa versione legge / proc direttamente dalla shell invece di generare un sotto-processo in un ciclo. È un po 'più veloce e probabilmente leggermente più elegante, come richiede questo titolo di discussione.

#!/bin/dash

# Print all descendant pids of process pid $1
# adapted from /unix//a/339071

ps=${1:-1}
while [ "$ps" ]; do
  echo $ps
  unset ps1 ps2
  for p in $ps; do
    read ps2 < /proc/$p/task/$p/children 2>/dev/null
    ps1="$ps1 $ps2"
  done
  ps=$ps1
done | tr " " "\n" | tail -n +2

In ciascuno dei tuoi due casi d'uso (apparentemente molto artificiali), perché vuoi uccidere alcuni sottoprocessi di processi sfortunati? Come fai a sapere meglio di un processo in cui i suoi figli dovrebbero vivere o morire? Mi sembra un design scadente; un processo dovrebbe ripulire dopo se stesso.

Se lo sai davvero meglio, allora dovresti biforcare questi sottoprocessi e il "processo demone" è apparentemente troppo stupido per essere attendibile fork(2).

Dovresti evitare di tenere un elenco di processi figlio o di frugare nella struttura dei processi, ad esempio inserendo i processi figlio in un gruppo di processi separato, come suggerito da @Gilles.

In ogni caso, sospetto che il tuo processo daemonizzato sarebbe meglio creare un pool di thread di lavoro (che necessariamente muore insieme al suo processo di contenimento) rispetto a un albero profondo di sub-sub-sub-processi, che qualcosa da qualche parte deve poi ripulire .

Ecco uno script wrapper pgrep che ti consente di usare pgrep e ottenere tutti i discendenti allo stesso tempo.

~/bin/pgrep_wrapper:

#!/bin/bash

# the delimiter argument must be the first arg, otherwise it is ignored
delim=$'\n'
if [ "$1" == "-d" ]; then
    delim=$2
    shift 2
fi

pids=
newpids=$(pgrep "$@")
status=$?
if [ $status -ne 0 ]; then
    exit $status
fi

while [ "$pids" != "$newpids" ]; do
    pids=$newpids
    newpids=$( { echo "$pids"; pgrep -P "$(echo -n "$pids" | tr -cs '[:digit:]' ',')"; } | sort -u )
done
if [ "$delim" != $'\n' ]; then
    first=1
    for pid in $pids; do
        if [ $first -ne 1 ]; then
            echo -n "$delim"
        else
            first=0
        fi  
        echo -n "$pid"
    done
else
    echo "$pids"
fi

Richiamare nello stesso modo in cui si invocherebbe il normale pgrep, ad esempio pgrep_recursive -U $USER javaper trovare tutti i processi e i processi secondari Java dell'utente corrente.