ninja-build/ninja

linux: `pool = console` does not forward signals (e.g. SIGTERM) to the console process

Open

#2.116 geöffnet am 2. Apr. 2022

Auf GitHub ansehen
 (2 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C++ (1.544 Forks)batch import
bughelp wanted

Repository-Metriken

Stars
 (10.194 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 39T 3h) (10 gemergte PRs in 30 T)

Beschreibung

If I have a simple build.ninja:

rule sleep
  command = $
    echo hi $
    && sleep 100

build sleep : sleep
  pool = console

And I run ninja sleep, I get a process tree like this:

sh (PID: 1)
└─ ninja sleep (PID: 2)
   └─ sleep 100 (PID: 3)

If I now send a SIGTERM to ninja (kill 2), I’d expect that signal to be forwarded to sleep. However, ninja will swallow the signal and nothing happens. The same happens with e.g. SIGINT.

If I remove pool = console, the SIGTERM is forwarded correctly (this was fixed in https://github.com/ninja-build/ninja/pull/743) cc @nicolasdespres

Forwarding signals is quite important if I want to run ninja processes inside a service manager. For example if I want to run ninja sleep (or any program executable I build) inside of s6, s6-supervise will send SIGTERM (or any other signal) to ninja sleep, expecting it to stop running.

Contributor Guide

Research-Richtung
Untersuche den Signalweiterleitungsmechanismus im Quellcode von ninja, insbesondere in `src/subprocess.cc` oder verwandten Dateien. Das Problem stellt fest, dass ohne `pool = console` Signale korrekt weitergeleitet werden (in PR #743 behoben). Für den Konsolen Pool finde heraus, wo die Prozessgruppe gesetzt wird oder wo Signalhandler konfiguriert sind. Vergleiche die Implementierung des Konsolen Pools mit dem Standard Pool, um die fehlende Signalweiterleitung zu identifizieren. Sieh dir an, wie `SIGTERM` und `SIGINT` im Subprozess Code behandelt werden. Erwäge, eine geeignete Signalweiterleitung für Konsolen Pool Prozesse hinzuzufügen.
Tech Stack
cpp
Domain
build system
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
2
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-3 Stunden
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
C++Signal handling
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
50