Ipython: Kernel/Interrupt Kernel beendet nicht hängende Teilprozesse im Notebook

Duplikat von #514

Danke, das Duplikat hatte ich nicht entdeckt. Allerdings diskutiert t#514 ein viel komplexeres Szenario, das die Interaktion mit Subprozessen beinhaltet (und es scheint Unix-basiert zu sein, da es sich um eine Interaktion im Pty-Stil handelt). Für meine Anforderungen wäre ein einfaches Mittel zum Töten eines Schurken-Unterprozesses ausreichend. Betrachten Sie etwas so Einfaches wie !sleep 50000 , bei dem Sie nur den Schlaf töten können. (Vielleicht funktioniert Strg-C dafür unter Unix, aber nicht unter Windows).

Entschuldigung, ich verstehe jetzt, was du meinst. Erneutes Öffnen als separates Problem - Unterbrechung, die Unterprozesse unter Windows nicht unterbricht.

Ich bin mir nicht sicher, ob dies auf Unterprozesse beschränkt ist. Versuchen Sie, input() oder raw_input() auszuführen und dann auf die Unterbrechungsschaltfläche zu klicken - der Kernel hängt und muss neu gestartet werden.

@arijun auf

Entschuldigung, Fenster. Deshalb dachte ich, es sei wahrscheinlich das gleiche Problem, das @pfmoore hatte, da dies auch unter Windows passiert ist.

Ach, Mist. Ich weiß, was das für ein Bug ist. Ich denke, es ist ein Fehler in libzmq (oder pyzmq), der verhindert, dass Interrupts beim Polling auf zmq-Sockets richtig verarbeitet werden. Es ist nichts in IPython. _Seufzen_

Ich glaube, ich wurde gerade davon gebissen und muss den Kernel neu starten, was bedeutet, dass ich gerade eine Menge Daten verloren habe…

Ich habe pdb , um eine Funktion zu debuggen. Ich habe die Zelle erneut ausgeführt, ohne zuerst pdb , und jetzt kann ich nichts mehr unterbrechen.

Hier ist ein Minimalbeispiel, das dies reproduziert:

def test():
    import pdb; pdb.set_trace()  # XXX BREAKPOINT
    return 0

test()

Führen Sie diese Zelle zweimal hintereinander aus.

Das gleiche Problem tritt bei mir auch unter Unix Wort für Wort auf.

"Wenn ein Unterprozess vom Notebook aus ausgeführt wird und er hängen bleibt, wird der Kernel gesperrt und wartet darauf. Die Auswahl von Kernel/Interrupt aus dem Menü beendet den Unterprozess nicht, sondern lässt den Kernel in einem instabilen, "teilweise gesperrten" Zustand zurück , wo andere Zellen nicht ausgeführt werden. Die einzige Lösung besteht darin, den Kernel neu zu starten."

Danke für das schöne Beispiel für einen pdb-Hang, wmayner. Da pdb jedoch nicht in einem Unterprozess läuft, habe ich ein separates Problem für pdb geöffnet: #10516

Das Drucken von zu vielen Daten, sagen wir, das versehentliche Drucken eines riesigen numpy-Arrays kann dazu führen, dass der Kernel vollständig nicht mehr reagiert und es unmöglich ist, ihn zu beenden

Wurde für dieses Problem schon eine Lösung gefunden? Ich habe gerade ein Modell für maschinelles Lernen ausgeführt, dessen Fertigstellung 14 Stunden gedauert hat, und jetzt hängt mein Kernel fest und führt keine Zellen aus. Wenn ich neu starte, muss ich das Modell erneut 14 Stunden lang laufen lassen. Gibt es also eine Lösung?

Ich habe es noch nicht ausprobiert, aber es scheint, als könnte es helfen: http://jupyter-contrib-nbextensions.readthedocs.io/en/latest/nbextensions/limit_output/readme.html

Wenn ein bestimmter Unterprozess stecken geblieben ist, können Sie ihn wahrscheinlich im Task-Manager finden und auf diese Weise gewaltsam beenden. Hoffentlich lässt der Kernel damit weiter.

Nein, das Problem ist, dass der Kernel den Webserver zu Tode spammt oder so. Das Töten des Webservers tötet den Kernel afaik

Ich habe es auch mit einem steckengebliebenen Notebook zu tun: unterbrechen, neu starten, wieder verbinden - keiner von ihnen tut etwas. Die [*] Indikatoren bleiben neben den Zellen, als ob sie zur Ausführung in die Warteschlange gestellt würden, aber keine Zellen werden ausgeführt.

Das Verhalten begann, nachdem eine Zelle ausgeführt wurde, die Folgendes enthielt:

filedir = "20161214_rooftest"

!ls -RC $filedir

Was seltsam ist, da ich an anderer Stelle analoge Zellen habe, die erfolgreich ausgeführt werden. Ich bin mir nicht sicher, wie / ob ls stecken bleiben könnte, aber ansonsten scheint meine Situation diesem Problem zu entsprechen.

Gibt es hierfür eine Lösung. Kernal kann nicht unterbrochen werden.
Bei mir passiert das mit GridSearchCV in sklearn .

Es gab einen Prozess namens conda.exe im Task-Manager. Ich habe diesen Prozess beendet und konnte den Kernel erfolgreich unterbrechen

Interrupt ist immer noch kaputt. Ich muss meine Importe jedes Mal neu starten und neu laden.

gleiches Problem in Jupyter Lab auf Python 3.7 Kernel

Das gleiche Problem in Jupyter Notebook und ich kann den Prozess namens conda.exe im Task-Manager nicht finden. Gibt es schon Updates zur Lösung?

Keine Lösung
Manchmal hilft es in diesem Fall, sich wieder mit dem Kernel zu verbinden

Beobachte das gleiche in Windows 10

Ist das jemandem gelungen? ich werde verrückt

Es gab einen Prozess namens conda.exe im Task-Manager. Ich habe diesen Prozess beendet und konnte den Kernel erfolgreich unterbrechen

@ahmedrao Wie????

Dieses Problem besteht seit sechs Jahren und immer noch keine Lösung.

Dieses Problem besteht seit sechs Jahren und immer noch keine Lösung.

sechs Jahre ohne Lösung, einfach den Kernel neu starten

Das gleiche Problem immer häufiger zu haben, fast so weit, dass die Notebooks unbrauchbar werden, was wirklich schade ist. Bei Anaconda 3.7 hängen die Zellen einfach mit dem Sternchen und ich kann den Kernel nicht unterbrechen.

Gleiches Problem markieren

Hatte immer dieses Problem, besonders mit dbg und input.
Windows10; Notebook-Server 5.7.8; Python 3.6.6.; Conda 4.7.5
Habe gelernt, dass ich Notebooks grundsätzlich nicht zuverlässig debuggen kann :(

ja, das Problem besteht immer noch. Gibt es eine Möglichkeit das zu überwinden?? Ich möchte mein Notebook nicht noch einmal laufen lassen, weil es zu lange dauert, bis ich dort bin, wo ich bin !!

Hoch!
Dieses Problem bereitet mir seit Jahren jedes Mal, wenn ich pdb verwende und vergesse, aufzuhören, bevor ich die Zelle erneut starte.

Ich habe ein Kopfgeld auf BountySource erstellt. Vielleicht wird das endlich behoben, wenn wir genug Geld zusammenbekommen.
https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

Für das Prozessproblem speziell unter Windows ist hier eine Theorie (noch ungetestet):

1. Der Prozess wird über IPython.utils._process_win32.system , das _system_body aufruft, das p.wait() für das Objekt subprocess.Popen aufruft.
2. Windows subprocess.Popen.wait() hat ein bekanntes Problem, bei dem es nicht unterbrechbar ist: https://bugs.python.org/issue28168

Wenn dies die Ursache ist, würde das Umschalten auf Busy-Loop alle 100 ms oder so wahrscheinlich unterbrechbar machen, oder wenn nicht, dann den Ansatz im Patch verwenden.

Danke @Carreau!

Danke @Carreau! Wann wird dies Eingang in ein allgemeines Release finden und bedeutet das, dass wir den Interrupt-Kernel-Button dann erfolgreich nutzen können?

Ich werde morgen wahrscheinlich eine 7.13 machen. Es könnte die Unterbrechungstaste reparieren.

Hey @Carreau
Ich stehe vor diesem Problem, wenn ich versuche, eine laufende Zellenausführung zu unterbrechen, die Unterbrechung für immer andauert und ich endlich neu starten muss.

Um dies zu demonstrieren, schlug @wmayner eine Möglichkeit vor, das Problem zu replizieren. Dazu habe ich ein paar Screenshots angehängt.

Jupyter-Versionen in meinem Computer.

@Arpit-Gole pdb ist ein eigenes spezifisches Problem; Ich hoffe, dass auch das bald behoben wird: https://github.com/ipython/ipython/issues/10516

@itamarst Ich trainiere ein Modell wie folgt:

forest_clf = RandomForestClassifier() cross_val_score(forest_clf, X_train, y_train, cv=3, scoring='accuracy', verbose=10, n_jobs=-1)

Jetzt weiß ich, dass es aufgrund meines Datensatzes sicherlich zeitaufwändig sein wird. Aber sagen Sie, aus welchem ​​​​Grund auch immer, ich beschließe, die Verarbeitung auf halbem Weg zu stoppen, indem ich Kernel>Interrupt Kernel drücke .
Idealerweise sollte es unterbrechen, aber es dauert ewig, bis es aufhört.
Jetzt möchte ich nicht neu starten, da alle meine Fortschritte weg sind.

Bitte helfen Sie!

Wenn das, was Sie zu unterbrechen versuchen, in C implementiert ist, gibt es nichts zu tun. Es liegt an der Bibliothek, die Sie für die Verarbeitung von sigint verwenden.

Ich stoße auch manchmal darauf ... Hier ist ein reproduzierbares Beispiel aus dem Jupyer Lab:

LADE DATEN

import requests
import pandas as pd

url='https://raw.githubusercontent.com/numenta/NAB/master/data/realKnownCause/nyc_taxi.csv'
r = requests.get(url, allow_redirects=True)
        with open('data/nyc_taxi.csv', 'wb') as f:
            f.write(r.content)
df_taxi = (
        pd.read_csv('data/nyc_taxi.csv')
        .assign(timestamp=lambda x: pd.to_datetime(x.timestamp))
)

df_train = df_taxi.iloc[:5000]
temp_train = df_train.set_index('timestamp')

Rastersuche ausführen: DIES KANN NICHT UNTERBROCHEN WERDEN

import itertools
#set parameter range
p = range(0,3)
q = range(1,3)
d = range(1,2)
s = [24,48]

# list of all parameter combos
pdq = list(itertools.product(p, d, q))
seasonal_pdq = list(itertools.product(p, d, q, s))
# SARIMA model pipeline
for param in pdq:
    for param_seasonal in seasonal_pdq:
        try:
            mod = sm.tsa.statespace.SARIMAX(temp_train[:240],
                                            order=param,
                                            seasonal_order=param_seasonal)

            results = mod.fit(max_iter = 50, method = 'powell')

            print('SARIMA{},{} - AIC:{}'.format(param, param_seasonal, results.aic))
        except as e:
            print(e)
            continue

Gibt es Ratschläge?

bin heute nachmittag dreimal auf dieses problem gestoßen, erinnert mich an die gute alte zeit, als ich noch urllib benutzte.
dachte, es wäre auf urllib, weil es keine Antwort auf meine Anfrage gibt.
Ich habe gearbeitet, aber codiert, ich muss eine Lösung finden, aber eine Antwort. Also speichere ich jede Variable in einer lokalen Datei.
will das wirklich nicht immer wieder erleben.

Ich stehe vor dem gleichen Problem, wenn ich Tensorflow und GPU zum Trainieren des Deep-Learning-Modells verwende.

Gehen Sie mit time.sleep und Anfragen darauf ein

Habe auch dieses Problem mit time.sleep-Anfragen unter Windows, läuft aber unter Mac OS X gut

Habe dieses Problem mit ThreadPoolExecutor... Etwa so:

numberOfImageGatherers = 2

with concurrent.futures.ThreadPoolExecutor(max_workers=numberOfImageGatherers + 1) as executor:
        futures = []

        for imageGatherer in range(numberOfImageGatherers):
            imageDataGatherer = ImageDataGatherer(batch_size)
            futures.append(executor.submit(imageDataGatherer.gatherImageData, pipeline))

        modelTrainingConsumer = ModelTrainingConsumer(vae, plot_losses)    

        futures.append(executor.submit(modelTrainingConsumer.trainModel, pipeline))

        concurrent.futures.wait(futures)

Die einzige Möglichkeit zu unterbrechen besteht darin, den Kernel neu zu starten ... sehr frustrierend