Ipython: Ядро / прерывание Ядро не завершает зависшие подпроцессы в записной книжке

дубликат № 514

Спасибо, дубликат не заметил. Сказав это, t # 514 обсуждает гораздо более сложный сценарий, предполагающий фактическое взаимодействие с подпроцессами (и, похоже, он основан на Unix, поскольку речь идет о взаимодействии в стиле pty). Для моих требований подойдет простое средство уничтожения подпроцесса-мошенника. Рассмотрим что-нибудь простое, например, !sleep 50000 , где просто возможность убить сон - это все, что вам нужно. (Возможно, Ctrl-C работает для этого в Unix, но не в Windows).

Извините, теперь я понимаю, что вы имеете в виду. Повторное открытие как отдельная проблема - прерывание без прерывания подпроцессов в Windows.

Я не уверен, что это ограничивается подпроцессами. Попробуйте выполнить input() или raw_input() а затем нажмите кнопку прерывания - ядро ​​зависает и необходимо перезапустить.

@arijun на какой ОС? прерывание ввода и raw_input вызывают здесь KeyboardInterrupt (OS X).

Простите, окна. Вот почему я подумал, что это, вероятно, та же проблема, что и у @pfmoore , поскольку это также происходило в Windows.

Вот дерьмо. Я знаю, что это за ошибка. Я думаю, что это ошибка libzmq (или pyzmq), которая не позволяет ему правильно обрабатывать прерывания при опросе сокетов zmq. В IPython ничего нет. _вздох_

Я думаю, что меня это просто укусило, и мне нужно перезапустить ядро, то есть я только что потерял много данных ...

Я использовал pdb для отладки функции. Я повторно запустил ячейку, не выйдя сначала из pdb , и теперь я не могу ничего прервать.

Вот минимальный пример, который воспроизводит это:

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

test()

Выполните эту ячейку дважды подряд.

Эта же проблема встречается у меня и в Unix, слово в слово.

«Когда подпроцесс запускается из записной книжки, в случае его зависания ядро ​​будет заблокировано, ожидая его. Выбор« Ядро / Прерывание »в меню не завершает подпроцесс, а скорее оставляет ядро ​​в нестабильном,« частично заблокированном »состоянии. , где другие ячейки не работают. Единственное решение - перезапустить ядро ​​".

Спасибо за хороший пример зависания pdb, wmayner. Но так как pdb не работает в подпроцессе, я открыл отдельную проблему для pdb: # 10516

Печать слишком большого количества данных, скажем, случайная печать гигантского массива numpy, может привести к тому, что ядро ​​полностью перестанет отвечать, и его невозможно будет завершить.

Решение этой проблемы уже найдено? Я только что запустил модель машинного обучения, выполнение которой заняло 14 часов, и теперь мое ядро ​​зависло и не выполняет ячейки. если я перезапущусь, мне придется снова запустить модель в течение 14 часов. Так есть ли какое-нибудь решение?

не пробовал, но похоже, что это может помочь: http://jupyter-contrib-nbextensions.readthedocs.io/en/latest/nbextensions/limit_output/readme.html

Если определенный подпроцесс застрял, вы, вероятно, можете найти его в диспетчере задач и принудительно убить его таким образом. Надеюсь, это позволит ядру продолжить работу.

нет, проблема в том, что ядро ​​спамило веб-сервер до смерти или что-то в этом роде. убийство веб-сервера убивает ядро ​​afaik

Я тоже имею дело с застрявшим ноутбуком: прерывание, перезагрузка, повторное подключение - никто из них ничего не делает. Индикаторы [*] остаются рядом с ячейками, как если бы они были поставлены в очередь для выполнения, но ячейки не выполняются.

Поведение началось после запуска ячейки, содержащей:

filedir = "20161214_rooftest"

!ls -RC $filedir

Это странно, потому что у меня есть аналогичные ячейки в другом месте, которые успешно работают. Я не уверен, как / если ls может застрять, но в остальном моя ситуация, похоже, соответствует этой проблеме.

Есть ли какое-то решение для этого. Кернал не может быть прерван.
Для меня это происходит с GridSearchCV в sklearn.

В диспетчере задач был процесс с именем conda.exe. Я убил этот процесс и смог прервать работу ядра.

Прерывание все еще не работает. Мне каждый раз приходится перезапускать и перезагружать импорт.

такая же проблема в лаборатории jupyter на ядре python 3.7

та же проблема в Jupyter Notebook, и я не могу найти процесс с именем conda.exe в диспетчере задач. Есть какие-нибудь обновления решения?

Не решение
Иногда в этом случае помогает попытка переподключиться к ядру

Наблюдая то же самое в Windows 10

Кому-нибудь это удалось? схожу с ума

В диспетчере задач был процесс с именем conda.exe. Я убил этот процесс и смог прервать работу ядра.

@ahmedrao Как ????

Эта проблема существует уже шесть лет и до сих пор не решена.

Эта проблема существует уже шесть лет и до сих пор не решена.

шесть лет без решения, просто перезапустите ядро

Одна и та же проблема возникает все чаще, почти до такой степени, что ноутбуки становятся непригодными для использования, что является настоящим позором. В Anaconda 3.7 ячейки просто зависают со звездочкой, и я не могу прервать работу ядра.

Отметить ту же проблему

Всегда была эта проблема, особенно с dbg и вводом.
Windows 10; Ноутбук-сервер 5.7.8; Python 3.6.6 .; Конда 4.7.5
Узнал, что я в принципе не могу надежно отлаживать ноутбуки :(

да, проблема все еще существует. Есть ли способ преодолеть это ?? Я не хочу запускать свой ноутбук снова и снова, потому что мне нужно слишком много времени, чтобы добраться туда, где я !!

Вверх!
Эта проблема была для меня головной болью в течение многих лет каждый раз, когда я использую pdb и забываю завершить работу перед повторным запуском ячейки.

Я создал награду на BountySource. Может быть, это, наконец, исправят, если мы соберем достаточно денег.
https://www.bountysource.com/issues/44958889-hang-after-running-pdb-in-a-cell-kernel-interrupt-doesn-t-help

Что касается проблемы процесса, в частности, в Windows, вот теория (все еще не проверенная):

1. Процесс запускается через IPython.utils._process_win32.system , который вызывает _system_body , который вызывает p.wait() subprocess.Popen объекта
2. В Windows subprocess.Popen.wait() есть известная проблема, из-за которой его нельзя прервать: https://bugs.python.org/issue28168

Если это причина, переключение на цикл занятости каждые 100 мс или около того, вероятно, сделало бы его прерываемым, а если нет, то примените подход в патче.

Спасибо, @Carreau!

Спасибо @Carreau! Когда это войдет в общий выпуск и означает ли это, что мы сможем успешно использовать кнопку «Прервать ядро»?

Скорее всего завтра сделаю 7,13. Это может исправить кнопку прерывания.

Привет @Carreau
Я сталкиваюсь с этой проблемой, когда пытаюсь прервать текущее выполнение ячейки, прерывание продолжается вечно, и, наконец, мне нужно перезапустить.

Итак, чтобы продемонстрировать, как @wmayner предложил способ воспроизвести проблему. Я приложил несколько скриншотов к тому же.

Версии Jupyter на моей машине.

@ Arpit-Gole pdb - это отдельная проблема; Я тоже надеюсь исправить это в ближайшее время: https://github.com/ipython/ipython/issues/10516

@itamarst Я тренирую модель следующим образом:

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

Теперь я знаю, что это обязательно займет время в зависимости от моего набора данных. Но скажем, по какой-то причине я решил остановить обработку на полпути, нажав Kernel> Interrupt Kernel .
В идеале он должен прерываться, но для остановки требуется вечность.
Теперь я не хочу перезапускать, потому что весь мой прогресс исчезнет.

Пожалуйста помоги!

Если то, что вы пытаетесь прервать, реализовано на C, то делать нечего. Это зависит от библиотеки, которую вы используете для обработки sigint.

Я тоже иногда сталкиваюсь с этим ... Вот воспроизводимый пример из лаборатории jupyer:

ЗАГРУЗИТЬ ДАННЫЕ

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

Запустить поиск по сетке: ЭТО НЕ МОЖЕТ БЫТЬ ПРЕРЫВАТЬ

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

Есть какие-нибудь советы?

Трижды столкнулся с этой проблемой сегодня днем, это напоминает мне о старых добрых временах, когда я все еще использовал urllib.
думал, что это на urllib, потому что на мой запрос нет ответа.
Я работал, но кодировал, мне нужно найти решение, но ответ. Поэтому я сохраняю каждую переменную в локальном файле.
действительно не хочу, чтобы это повторялось снова и снова.

Я сталкиваюсь с той же проблемой при использовании тензорного потока и графического процессора для обучения модели глубокого обучения.

Столкнитесь с этим с time.sleep и запросами

Также есть проблема с запросами time.sleep в Windows, но отлично работает в Mac OS X

Возникла эта проблема с ThreadPoolExecutor ... Примерно так:

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)

Единственный способ прервать его - перезапустить ядро ​​... очень неприятно