Ipython: Kernel/Interrupt Kernel ne met pas fin aux sous-processus bloqués dans le bloc-notes

duplicata du #514

Merci, je n'avais pas repéré le doublon. Cela dit, t#514 discute d'un scénario beaucoup plus complexe, impliquant en fait une interaction avec des sous-processus (et il semble être basé sur Unix, car il s'agit d'interaction de style pty). Pour mes besoins, un moyen simple de tuer un sous-processus malveillant ferait l'affaire. Considérez quelque chose d'aussi simple que !sleep 50000 , où le simple fait de pouvoir tuer le sommeil est tout ce que vous voulez. (Peut-être que Ctrl-C fonctionne pour cela sous Unix, mais pas sous Windows).

Désolé, je vois ce que tu veux dire maintenant. Réouverture en tant que problème distinct - interrompre sans interrompre les sous-processus sous Windows.

Je ne suis pas sûr que cela se limite aux sous-processus. Essayez d'exécuter input() ou raw_input() puis cliquez sur le bouton d'interruption -- le noyau se bloque et doit être redémarré.

@arijun sur quel système d'exploitation ? l'interruption de l'entrée et raw_input lèvent KeyboardInterrupt ici (OS X).

Désolé, fenêtres. C'est pourquoi j'ai pensé qu'il s'agissait probablement du même problème que @pfmoore , car cela s'est également produit sur Windows.

Ah, merde. Je sais quel est ce bug. Je pense que c'est un bogue libzmq (ou pyzmq) qui l'empêche de gérer correctement les interruptions lors de l'interrogation sur les sockets zmq. Ce n'est rien dans IPython. _soupir_

Je pense que je viens de me faire piquer et que je vais devoir redémarrer le noyau, ce qui signifie que je viens de perdre beaucoup de données…

J'utilisais pdb pour déboguer une fonction. J'ai réexécuté la cellule sans d'abord quitter pdb , et maintenant je ne peux plus rien interrompre.

Voici un exemple minimal qui reproduit ceci :

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

test()

Exécutez cette cellule deux fois de suite.

Ce même problème se produit pour moi sous Unix aussi mot pour mot.

"Lorsqu'un sous-processus est exécuté à partir du notebook, s'il reste bloqué, le noyau sera verrouillé en l'attendant. Sélectionner Kernel/Interruption dans le menu ne termine pas le sous-processus, mais laisse plutôt le noyau dans un état instable, "partiellement verrouillé" , où les autres cellules ne s'exécutent pas. La seule solution est de redémarrer le noyau."

Merci pour le bel exemple de blocage de pdb, wmayner. Mais comme pdb ne s'exécute pas dans un sous-processus, j'ai ouvert un problème distinct pour pdb : #10516

Imprimer trop de données, disons imprimer accidentellement un gigantesque tableau numpy, peut rendre le noyau complètement insensible et impossible à terminer

Une solution a-t-elle déjà été trouvée pour ce problème ? Je viens d'exécuter un modèle d'apprentissage automatique qui a pris 14 heures et maintenant mon noyau est bloqué et n'exécute pas de cellules. si je redémarre, je dois réexécuter le modèle pendant 14 heures. Alors y a-t-il une solution ?

Je ne l'ai pas essayé, mais cela semble pouvoir aider : http://jupyter-contrib-nbextensions.readthedocs.io/en/latest/nbextensions/limit_output/readme.html

Si un sous-processus spécifique est bloqué, vous pouvez probablement le trouver dans le gestionnaire de tâches et le tuer de force de cette façon. Espérons que cela permet au noyau de continuer.

non, le problème est que le noyau spamme le serveur Web à mort ou quelque chose du genre. tuer le serveur Web tue le noyau autant que je sache

J'ai aussi affaire à un bloc-notes bloqué : interrompre, redémarrer, reconnecter - aucun d'entre eux ne fait rien. Les indicateurs [*] restent à côté des cellules comme si elles étaient en file d'attente pour s'exécuter mais aucune cellule n'est exécutée.

Le comportement a commencé après l'exécution d'une cellule contenant :

filedir = "20161214_rooftest"

!ls -RC $filedir

Ce qui est étrange parce que j'ai des cellules analogues ailleurs qui fonctionnent avec succès. Je ne sais pas comment/si ls pourrait rester bloqué, mais sinon ma situation semble correspondre à ce problème.

Y a-t-il une solution à cela . Le noyau ne peut pas être interrompu.
Pour moi, cela se passe avec GridSearchCV dans sklearn .

Il y avait un processus nommé conda.exe dans le Gestionnaire des tâches. J'ai tué ce processus et j'ai réussi à interrompre le noyau

L'interruption est toujours interrompue. Je dois redémarrer et recharger mes importations à chaque fois.

même problème dans jupyter lab sur le noyau python 3.7

même problème dans Jupyter Notebook et je ne trouve pas le processus nommé conda.exe dans le gestionnaire de tâches. Des mises à jour sur la solution pour le moment?

Pas une solution
Parfois, essayer de se reconnecter au noyau aide dans ce cas

Observant la même chose, dans Windows 10

Quelqu'un a-t-il réussi là-dessus ? je deviens fou

Il y avait un processus nommé conda.exe dans le Gestionnaire des tâches. J'ai tué ce processus et j'ai réussi à interrompre le noyau

@ahmedrao Comment ????

Ce problème existe depuis six ans et toujours pas de solution.

Ce problème existe depuis six ans et toujours pas de solution.

six ans sans aucune solution, il suffit de redémarrer le noyau

Avoir le même problème de plus en plus fréquemment, presque au point que les notebooks deviennent inutilisables ce qui est vraiment dommage. Sur Anaconda 3.7 et les cellules se bloquent juste avec l'astérisque, et je ne peux pas interrompre le noyau.

Marquer le même problème

J'ai toujours eu ce problème surtout avec dbg et input.
Windows 10 ; Serveur de bloc-notes 5.7.8 ; Python 3.6.6.; Conda 4.7.5
J'ai appris que je ne peux fondamentalement pas déboguer de manière fiable les ordinateurs portables :(

oui, le problème existe toujours. Y a-t-il un moyen de surmonter cela ?? Je ne veux pas recommencer mon cahier, car cela prend trop de temps pour arriver là où je suis !!

En haut!
Ce problème est pénible pour moi depuis des années maintenant chaque fois que j'utilise pdb et que j'oublie de quitter avant de relancer la cellule.

J'ai créé une prime sur BountySource. Peut-être que cela sera enfin corrigé si nous pouvons rassembler suffisamment d'argent.
https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

Pour le problème du processus en particulier, sous Windows en particulier, voici une théorie (encore non testée) :

1. Le processus est exécuté via IPython.utils._process_win32.system , qui appelle _system_body , qui appelle p.wait() sur l'objet subprocess.Popen .
2. Windows subprocess.Popen.wait() a un problème connu où il n'est pas interruptible : https://bugs.python.org/issue28168

Si c'est la cause, passer en boucle occupée toutes les 100 ms environ le rendrait probablement interruptible, ou sinon, adopterait l'approche dans le patch.

Merci @Carreau !

Merci @Carreau ! Quand cela se retrouvera-t-il dans une version générale, et cela signifie-t-il que nous pourrons alors utiliser le bouton Interrupt Kernel avec succès ?

Je ferai probablement un 7.13 demain. Cela pourrait corriger le bouton d'interruption.

Salut @Carreau
Je suis confronté à ce problème lorsque j'essaie d'interrompre l'exécution d'une cellule en cours, l'interruption se poursuit indéfiniment et je dois enfin redémarrer.

Donc, afin de le démontrer, comme @wmayner a suggéré un moyen de reproduire le problème. J'ai joint quelques captures d'écran pour la même chose.

Versions Jupyter dans ma machine.

@Arpit-Gole pdb est son propre problème spécifique; J'espère également que cela sera corrigé bientôt : https://github.com/ipython/ipython/issues/10516

@itamarst je forme un modèle comme suit :

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

Maintenant, je sais que cela prendra forcément du temps en fonction de mon ensemble de données. Mais disons, pour une raison quelconque, que je choisis d'arrêter le traitement à mi-chemin en appuyant sur Kernel> Interrupt Kernel .
Idéalement, il devrait s'interrompre, mais il faut une éternité pour s'arrêter.
Maintenant, je ne veux pas redémarrer car tous mes progrès auront disparu.

S'il vous plaît, aidez-nous !

Si ce que vous essayez d'interrompre est implémenté en C, il n'y a rien à faire. C'est à la bibliothèque que vous utilisez pour gérer sigint.

Je rencontre parfois ça aussi... Voici un exemple reproductible de jupyer lab :

CHARGER LES DONNÉES

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')

Exécuter la recherche de grille : CECI NE PEUT PAS ÊTRE INTERROMPU

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

Y a-t-il des conseils?

rencontré ce problème trois fois cet après-midi, me rappelle le bon vieux temps où j'utilisais encore urllib.
Je pensais que c'était sur urllib, car il n'y a pas de réponse à ma demande.
Je travaillais mais en codant, je dois trouver une solution mais une réponse. Je stocke donc chaque variable dans un fichier local.
Je ne veux vraiment pas que cela se reproduise encore et encore.

Je suis confronté au même problème lors de l'utilisation de tensorflow et de GPU pour la formation d'un modèle d'apprentissage en profondeur.

Exécutez cela avec time.sleep et demandes

J'ai également ce problème avec les requêtes time.sleep sur Windows, mais fonctionne bien sur Mac OS X

Ayant ce problème avec ThreadPoolExecutor... Quelque chose comme ceci :

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)

Le seul moyen d'interrompre est de redémarrer le noyau... très frustrant