Início / unix / Perguntas / 789530
Accepted
Yakog
Asked: 2025-01-14 05:48:18 +0800 CST

Por que o comando kill não funciona para SIGTSTP, mas funciona para alguns outros sinais (SIGSTOP/SIGINT etc.)?

  • 772

Tenho os dois programas simples a seguir.

Pai:

package main

import (
    "fmt"
    "syscall"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
        Sys: &syscall.SysProcAttr{ // child in its own group
            Setpgid: true,
            Pgid:    0,
        },
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
}

Criança:

package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("hi from child")
        time.Sleep(time.Second * 5)
    }
}

Saída do ps:

yakog@yakog-computer:~/goprojects/parent$ ps -o pid,ppid,pgid,uid,wchan,stat,tt,command -t /dev/pts/19
    PID    PPID    PGID   UID WCHAN  STAT TT       COMMAND
1867701 1867320 1867701  1000 do_sel Ss+  pts/19   bash
1870508    2118 1870508  1000 ep_pol Sl   pts/19   child

Quando pressiono CTRL-Zou CTRL-C, não tem efeito algum. É exatamente o que eu esperava, já que o processo 1870508 não faz parte do trabalho de primeiro plano e CTRL-Z/ CTRL-Cinvoca kill -SIGTSTP -1867701/ kill -SIGINT -1867701. Portanto, 1870508 não recebe esses sinais.

Além disso, quando invoco kill -SIGINT 1870508ou kill -SIGSTOP 1870508, o processo é encerrado/suspenso. Ainda consigo entender. Embora 1870508 não faça parte do trabalho em primeiro plano, com killo comando enviamos "diretamente" o sinal para o processo .

No entanto, por que kill -SIGTSTP 1870508não funciona? Após iniciar o ./parentprocesso e chamar kill -SIGTSTP 1870508o comando, literalmente nada acontece (o 1870508 ainda tem status R/ Se continua a imprimir no terminal). Não consigo entender por que ele não suspendeu o processo (o moveu para T). Deve ser o mesmo que com -SIGINTe -SIGSTOP( nós enviamos "diretamente" -SIGTSTP para o processo ), no entanto, não tem efeito neste caso.

O estranho é que se alterarmos o código pai (código abaixo) e fizermos com que ele continue a execução após a criação do filho, ele kill -SIGTSTP 1870508funcionará como deveria (o filho será suspenso).

package main

import (
    "fmt"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    attr := &syscall.ProcAttr{
        Files: []uintptr{0, 1, 2},
        Sys: &syscall.SysProcAttr{ // child in its own group
            Setpgid: true,
            Pgid:    0,
        },
    }

    _, err := syscall.ForkExec("./child/child", []string{"child"}, attr)
    signal.Ignore(syscall.SIGTSTP)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    for {
        fmt.Println("hi from parent")
        time.Sleep(time.Second * 7)
    }
}

Além disso, quando eu invoco kill -SIGSTOP 1870508(movo o processo para To estado) e então invoco, kill -SIGINT 1870508o processo não é encerrado... Por quê?

bash

2 respostas

  1. Best Answer

    Ver info libc 'Job Control Signals':

    Quando um processo em um grupo de processos órfãos (*note Grupos de Processos Órfãos::) recebe um sinal 'SIGTSTP', 'SIGTTIN' ou 'SIGTTOU' e não o manipula, o processo não para. Parar o processo provavelmente não seria muito útil, já que não há um programa shell que perceba sua parada e permita que o usuário continue. O que acontece depende do sistema operacional que você está usando. Alguns sistemas podem não fazer nada; outros podem entregar outro sinal, como 'SIGKILL' ou 'SIGHUP'. Em sistemas GNU/Hurd, o processo morre com 'SIGKILL'; isso evita o problema de muitos processos órfãos parados espalhados pelo sistema.

    Ou a especificação POSIX :

    Se a ação padrão for parar o processo, a execução desse processo será temporariamente suspensa. Quando um processo para, um sinal SIGCHLD será gerado para seu processo pai, a menos que o processo pai tenha definido o sinalizador SA_NOCLDSTOP. Enquanto um processo estiver parado, quaisquer sinais adicionais que forem enviados ao processo não serão entregues até que o processo seja continuado, exceto SIGKILL que sempre encerra o processo de recebimento. Um processo que seja membro de um grupo de processos órfãos não poderá parar em resposta aos sinais SIGTSTP, SIGTTIN ou SIGTTOU. Nos casos em que a entrega de um desses sinais pararia tal processo, o sinal será descartado.

    Um grupo de processos órfãos é definido como:

    Um grupo de processo no qual o pai de cada membro é um membro do grupo ou não é um membro da sessão do grupo.

    E seu grupo de processos de ID 1870508 se qualifica, pois seu único processo (1870508) tem 2118 como pai, provavelmente o sub-ceifador filho ao qual ele foi reconectado após a morte de seu pai.

    • 2

  2. Todos os processos recebem sinais o tempo todo. Eles não se importam se estão em primeiro plano, segundo plano ou parados.

    As chaves ctrl-ze ctrl-cenviam o sinal para o processo em primeiro plano. Isso não significa que o processo deve estar em primeiro plano para receber um sinal, mas significa que se o processo não estiver em primeiro plano, ctrl-cenvia o sinal para algum outro processo. Então o comportamento não é diferente, é um processo diferente que recebe o comportamento. Sempre há algum processo em primeiro plano. Então se seu processo alvo estiver em segundo plano e você pressionar ctrl-cseu shell está recebendo o ctrl-c, e ele lida com isso ou ignora, mas não sai.

    Se um processo for suspenso ( Testado), ele recebe o sinal. No entanto, um processo pode capturar SIGINT e fazer processamento adicional, mas se for suspenso, o sinal será colocado em sua fila pendente e ele fará esse processamento (e então possivelmente sairá) quando não estiver mais suspenso.

    Experimentando enviar sinais para processos suspensos, notei que alguns sinais os fazem morrer imediatamente, e alguns exigem que sejam retomados antes que o sinal tenha efeito. Possivelmente há algo no processo (como uma biblioteca?) que define um manipulador de sinais para esses sinais para que ele possa fazer alguma limpeza (como liberar buffers) antes que o processo saia.

    • 0

relate perguntas