niekontrolowany rozproszony proces

116

Czasami widzę, że distnotedproces nagle się rozkręca i żuje 100% procesora (na jednym rdzeniu) i tonę pamięci, często w okolicach 1,5G. Zdarza się to kilka razy dziennie, zaczynając mniej więcej miesiąc temu.

Wiersz poleceń jest /usr/sbin/distnoted agenti jest uruchamiany przez launchd, z których żadne z nich nie pomaga. Zwykle działa od około 4 godzin do 24 godzin, zanim się włączy i ustali procesor.

Wyszukiwania internetowe mówią, że distnotedzarządza dostarczaniem powiadomień, a wiele innych osób zgłasza ten sam problem, ale nie znalazłem jeszcze rozwiązania. Niektórzy uważają, że zamknięcie aplikacji sprawcy (np. Skype) ją zatrzymuje, ale nie znalazłem jeszcze winowajcy na moim komputerze. Zwykle korzystam tylko z kilku aplikacji: Emacs (24.2 z Homebrew), Firefox, Adium i Dash.

Korzystam z Mavericks pod koniec 2012 13 "Retina MBP. Z góry dziękuję!

Aktualizacja:

Włączyłem distnotedlogowanie do dziennika systemowego, dotykając /var/log/do_dnserver_log, ale to niewiele pomaga. Widzę takie linie (uid 501 to ja, 89 jeszcze nie znalazłem):

distnoted[80011]: # distnote server agent  absolute time: 48754.144787848   civil time: Wed Nov 20 10:52:03 2013   pid: 80011 uid: 501  root: no
distnoted[20]: # distnote server daemon  absolute time: 2.808112262   civil time: Tue Nov 19 09:52:24 2013   pid: 20 uid: 0  root: yes
distnoted[444]: # distnote server agent  absolute time: 16.656997509   civil time: Tue Nov 19 09:52:38 2013   pid: 444 uid: 501  root: no
distnoted[1271]: # distnote server agent  absolute time: 52.518265717   civil time: Tue Nov 19 09:53:14 2013   pid: 1271 uid: 89  root: no
distnoted[689]: Interruption - exiting now.

Uruchomiłem również proces sudo dtruss -p PIDrozpędzania distnoted, który wyrzuca linie takie jak to:

kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
__disable_threadsignal(0x1, 0x0, 0x0)    = 0 0
__disable_threadsignal(0x1, 0x0, 0x0)    = 0 0
__disable_threadsignal(0x1, 0x0, 0x0)    = 0 0
kevent64(0x3, 0x7FFF7C3FD130, 0x1)       = 1 0
workq_kernreturn(0x20, 0x0, 0x1)         = 0 0
...
Ryan
źródło
Po prostu łowisz tutaj, ale czy przy jakiejś zmianie wszyscy płyniecie ? Wydaje mi się, że są ze sobą powiązane. Jeśli przestanę flux, gdy emacs oszaleje, emacs ulega awarii lub wraca do normy. Nie jestem pewien, czy to przypadek (zdarzyło się to tylko dwa razy), ale jeśli wszyscy to robią, może to być coś.
nie działam, ale może inni tak.
ryan
aquaemacs powoduje, że ten proces wywraca się na mnie.
maraton
Miałem bardzo podobny problem (prawdopodobnie ten sam problem) i mój problem zniknął z aktualizacją systemu operacyjnego 10.9.4.
Chris Quenelle,
Zauważyłem to dzisiaj. Winowajcą była aplikacja Dysk Google OS X (10.9) (1.17.7290.4094). Pierwszy raz to widziałem.
jordanpg

Odpowiedzi:

24

Podsumowanie z PO : To było świetne narzędzie do debugowania. Początkowo wskazywało to na ponowne indeksowanie systemu plików przez Spotlight, ale zawęziłem listę elementów, które wolno indeksować, i nadal widziałem problem. Skończyło się na ustawianiu pracy crona, by zabijać regularnie. Zobacz odpowiedź dalej.


Można debugować z rozproszeniem, tworząc plik. /var/log/do_dnserver_log Powoduje to, że CFNotificationCenterserwer ( distnoted) zapisuje informacje o wszystkich powiadomieniach w dzienniku systemowym.

Zacznę od tego, uruchomię ponownie i spojrzę na dziennik systemu, kiedy procesor przyspieszy. To powinno łatwo wyjawić winowajcę.

Więcej informacji na temat CFNotificationCenterdebugowania można znaleźć w oficjalnych dokumentach programistów tutaj: Nota techniczna TN2124> CFNotificationCenter

Temikus
źródło
dzięki! dobry telefon, teraz to zrobiłem. Nie widzę żadnych rozproszonych wpisów /var/log/system.log, ale również nie wyskoczył od czasu rozpoczęcia logowania. skrzyżowane palce.
ryan
Widzę teraz zniekształcone linie logów, ale nie są one zbyt przydatne. westchnienie. przykład:Nov 23 07:56:15 hell.local distnoted[2644]: # distnote server agent absolute time: 77.445654904 civil time: Sat Nov 23 07:56:15 2013 pid: 2644 uid: 89 root: no
ryan
Spróbuj dołączyć skrypt DTrace do tego procesu i zobacz, co faktycznie robi, zacznij od sudo dtruss -p PIDi zobacz, jakie syscalls robi ten proces, a jeśli są jakieś nieudane (status nie jest równy 0).
Temikus,
Co to jest UID 89 w twoim systemie? Czy zmienia się identyfikator UID w powiadomieniach? Czy pid 2644 odpowiada rozkładowi lub innemu procesowi?
Temikus,
dzięki za pomysły! jestem zaznajomiony strace, ale nie wiedziałem o tym dtruss. na pewno spróbuję to następnym razem. pids są po prostu odpowiadającym rozproszonym procesem, a jedyne uids to ja i _appserveradmwbudowany użytkownik systemu, o którym niewiele wiem.
ryan
33

Też to widziałem. Emacs 24.3.1, Mavericks 10.9.

Przekonałem się, że rozproszony proces uspokaja się w ciągu kilku sekund po wyjściu z Emacsa.

Złożyłem tutaj błąd Emacsa: http://permalink.gmane.org/gmane.emacs.bugs/80836

Don Tillman
źródło
2
Widoczny również w Emacs v23.4.1.
WilliamKF,
1
To samo tutaj. Nigdy nie wyobrażałem sobie, że to spowodowane przez Emacsa! Dzięki
Lionel Henry
1
Dla mnie mam odwrotny problem - Emacs zaczyna używać całego procesora, a zabicie rozproszonego użytkownika tymczasowo usuwa problem. W tym przypadku, patrząc na proces Emacsa, widzę wiele wątków - niepochodzących z Emacsa - wszystkie oczekujące na kolejkę / mutex com.apple.root.default-overcommit-Priority (uruchom lldb, „proces dołącz - pid” <pid> ”, a następnie„ wątek śledzić wszystko ”, aby zobaczyć je wszystkie)
jrg
i jest to ciekawa lektura na temat wszystkich tych wątków: newosxbook.com/articles/GCD.html (moje zabójstwo może być „magicznym piórkiem”, a nie tym, co przywraca je do normy)
jrg
Widoczny również z Emacsem v24.5 na OS X 10.11.3
Michael
23

Wiem, że jestem spóźniony na imprezę, ale jest to wyciek pamięci związany z emacami kakao na Mavericks, który jest naprawiony w bagażniku. Na razie jest łatka, której możesz użyć do zbudowania emacsa 24.3 za pomocą samej poprawki.

https://gist.github.com/anonymous/8553178


użytkownik68323
źródło
1
Zaktualizowałem do wersji nocnej z Emacsa dla Mac OS X (w marcu) i nadal mam problem. Wydaje się, że tak się stanie, jeśli utworzę interaktywną sesję dla R lub Clojure (języki programowania). Rozproszony proces będzie powoli wspinał się na GB pamięci RAM i zwolni ją, jak tylko wyjdę z Emacsa.
mattrepl
Ten sam problem, o którym wspomniał @mattrepl.
Amelio Vazquez-Reina
1
Wygląda na to, że Homebrew zintegrowało tę łatkę. Więc brew reinstall emacs --cocoa --with-gnutlsmoże rozwiązać problem. Ma to również zostać naprawione w wersji 24.4, ale nie osiągnęło to jeszcze stabilności.
mblakele,
Właśnie doświadczyłem tego problemu z Emacsem 24.5 (poprawka miała być 24.4) .. w moim przypadku Emacs pokazywał wirującą piłkę i rozproszony zabrał prawie 400% procesora (na top) i zabicie -9 emacsa nie działało, ale po zabiciu -HUP disnoted emacs odpowiedział na zabójstwo.
Michael
17

Od distnotedpewnego czasu mam te same problemy z El Capitan. Moje rozwiązanie nie jest tak surowe jak regularne zabijanie, raczej sprawdzam, czy wymyka się spod kontroli (wysokie użycie procesora), a następnie zabijam. Używam tego skryptu:

#!/bin/sh
#
# check for runaway distnoted, kill if necessary
#
PATH=/bin:/usr/bin
export PATH

ps -reo '%cpu,uid,pid,command' | 
    awk -v UID=$UID '
    /distnoted agent$/ && $1 > 100.0 && $2 == UID { 
        system("kill -9 " $3) 
    }
    '

Skrypt jest uruchamiany z crona co minutę z następującą linią w crontab:

*   *  *   *  *   sh "$HOME/bin/checkdistnoted"

W praktyce skrypt zabija distnotedraz lub dwa razy dziennie i zwykle dzieje się to po uruchomieniu backupd.

Dla tych, którzy nie są zadowoleni z używania powłoki OS X (wiersz poleceń), następujący skrypt zainstaluje zarówno checkdistnotedskrypt, jak i pozycję crontab:

#!/bin/sh
#
# install $HOME/bin/checkdistnoted
# setup crontab to run every minute
# 
# MWR Apr 2016
#

INSTALLCMD=bin/checkdistnoted
cd "$HOME"
[ ! -d bin ] && mkdir bin
[ -f $INSTALLCMD ] || {
    cat > $INSTALLCMD <<-"!!"
    #!/bin/sh
    #
    # check for runaway distnoted, kill if necessary
    #

    PATH=/bin:/usr/bin
    export PATH

    ps -reo '%cpu,uid,pid,command' | 
        awk -v UID=$UID '
        /distnoted agent$/ && $1 >= 100.0 && $2 == UID { 
            # kill distnoted agent with >= 100% CPU and owned by me
            system("kill -9 " $3) 
        }
        '
!!
    chmod +x $INSTALLCMD 
    echo installed $INSTALLCMD
}

INSTALLCRON="# check for runaway distnoted every minute:
* * * * * sh \"\$HOME/$INSTALLCMD\""
crontab -l | grep -q '$HOME'/$INSTALLCMD || {
    crontab -l > mycron
    echo "$INSTALLCRON" >> mycron
    crontab mycron
    rm mycron
    echo updated crontab
}

Musisz zapisać powyższe install_checkdistnoted.shna pulpicie, a następnie uruchomić Applications/Utilities/Terminali wpisać:

cd Desktop
sh install_checkdistnoted.sh 

Jeśli działa w pełni, wydrukuje potwierdzenie każdego z kroków. Skrypt nie nadpisze istniejącego checkdistnotedwpisu skryptu lub pliku crontab.

Michael Rourke
źródło
2
DZIĘKUJĘ CI! Rewelacyjne rozwiązanie, które pozwala mi pozostać niezauważonym, ale wyłącza je, gdy wymyka się spod kontroli. Dla innych ludzi takich jak ja, którzy mogą nie być zaznajomieni z uniksowym sposobem robienia rzeczy: 1). twój folder domowy nie będzie miał katalogu bin, utwórz folder bin pod swoją nazwą użytkownika i umieść tam skrypt jako plik tekstowy o nazwie „checkdisnoted”. 2). Aby utworzyć wpis crona, uruchom „crontab -e” w terminalu, naciśnij klawisz „i”, aby przejść do trybu wstawiania, i wklej całą linię gwiazdkami, a następnie naciśnij „esc”, aby wrócić do trybu poleceń, i wejdź „: wq”, aby zapisać plik i wyjść z edytora.
Mike
@Michael Rourke: To świetne rozwiązanie. Jednak skrypt instalacyjny zawiera błędy składniowe w wbudowanym bashie mojego Maca „GNU bash, wersja 3.2.57 (1) -release (x86_64-apple-darwin15)”. „||” skrót logiczny i „<< -” nie działają tutaj.
kakyo
@kakyo - bardzo przykro, skrypt nie powiódł się, ponieważ tabulator stał się spacjami - naprawiono teraz.
Michael Rourke,
8

poddałem się i przyjąłem młot kowalski: zabijaj go automatycznie, co minutę. westchnienie.

umieszczam to w ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist:

<plist version="1.0">
<dict>
  <key>Label</key>
  <string>org.snarfed.pkill_distnoted</string>
  <key>ProgramArguments</key>
  <array>
    <string>pkill</string>
    <string>-KILL</string>
    <string>-f</string>
    <string>distnoted</string>
  </array>
  <key>StartInterval</key>
  <integer>60</integer>  <!-- every minute -->
</dict>
</plist>

a następnie zainstalowałem za pomocą launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

Ryan
źródło
1
Podejście Michaela Rourke poniżej jest czyszczeniem dotykowym, ponieważ zabija niezauważone, gdy zaczyna jeść procesor.
Mike
@mike, ale podejście Michaela Rourke'a nie zajmuje się przypadkami disnotedjedzenia RAM.
Cœur
@ Cœur - Tak. Nie doświadczyłem problemu z niezadowoleniem z jedzenia pamięci RAM. Czy to był problem, który widziałeś?
Mike
1
@mike tak, jadłem disnotedwczoraj 63 GB pamięci RAM na mojej High Sierra. Nawet Ryan, w swoim pytaniu, stwierdza, że proces żucia się mnóstwo pamięci .
Cœur
@ Cœur - dobry punkt! Głosowałem za nimi.
Mike
4

Robiłem różne kombinacje dostosowywania stripingu, aby zawęzić to zachowanie; Myślę, że to tryb komend. W wersji 10.9 z emacs 24.3.1 z homebrew (lub z emacsforosx) rozproszony + wyciek emacsa (oba powoli zwiększają zużycie pamięci) nastąpi przy otwartym buforze w trybie powłoki. Nie zrobi tego, jeśli tylko przejdziesz do plików.

Chciałem tylko to tutaj zauważyć, gmane wydaje się być wyłączony i wciąż znajduję tę dyskusję podczas moich dwa razy w tygodniu poszukiwań kontynuacji tego problemu.

Lang Martin
źródło
dzięki! może faktycznie widzę to samo. myślałem, że kastracja w centrum uwagi (zaakceptowana odpowiedź) zadziałała dla mnie, ale mimo wszystko wciąż widzę niekontrolowane zniekształcenia. jeszcze raz dziękuję za prowadzenie, mogę śledzić to i debugować więcej.
ryan 12.12.13
Wierzę, że jest to również coś, co dotyczy mojego procesu Emacsa. zdenerwowany uspokoił się po tym, jak zabiłem Emacsa. Mam serwer.el, edit-server.el i powłokę Pythona działającą przez cały czas dla rekordu.
Lester Cheung,
Widząc to samo! Emacs do winy!
justingordon
Nie wiem nawet, co to jest tryb komend, i czasami mam rozczochrany problem z emacsem. Może więc nie jest to wina żadnego konkretnego pakietu.
huyz
2

Wydaje mi się, że pamiętam tylko dwa przypadki, w których rozproszony szaleje. Przy tej okazji 2 z nich siedziały na szczycie listy procesorów, a jeden miał ponad 400%. Stało się to krótko po powrocie do biura i podłączeniu kilku zewnętrznych wyświetlaczy - z których jeden jest zasilany z portu USB - domyśliłem się, że może to być związane. Nie zrobiłem nic innego, aby spróbować rozwiązać problem, zanim wyciągnąłem wyświetlacz USB, co natychmiast przywróciło zdrowie psychiczne. A następnie podłączenie go ponownie nie spowodowało powtórzenia problemu.

Co udowadnia co? Brak pomysłu!

Podłączam je setki razy i po raz pierwszy przyszło mi do głowy, że może to być związane. A ponieważ nie zdarza się to za każdym razem, gdy je podłączam, może to mieć coś wspólnego ze zbyt szybkim podłączaniem ich obu do siebie, lub czymś losowym. W każdym razie pomyślałem, że podzielę się, na wypadek gdyby inni zauważyli, że ma to coś wspólnego z podłączaniem urządzeń peryferyjnych (jeśli taki jest ekran zewnętrzny)

petednz - fuzion
źródło
Miałem podobną sytuację. Kiedy odłączyłem moją kartę graficzną USB przestałem zużywać nadmierny procesor (zgodnie z „górą”), a kiedy ponownie ją podłączyłem, problem nie pojawił się od razu.
Dalbergia,
To również okazało się dla mnie problemem. Dziękuję Ci!
Eric Simonton,
2

Wydaje się, że dzieje się tak, gdy aplikacja w niewłaściwy sposób korzysta z interfejsu API powiadomień udostępnianego przez system macOS. W moim przypadku winowajcą był iTerm2. Po wyjściu z distnotedprocesu procesy zakończyły się. Inni zidentyfikowani sprawcy to Emacs i iTunes.

xApple
źródło
1
iTerm2 powoduje to również dla mnie.
ctc
0

Warto było rozwiązać ten problem, wyłączając oprogramowanie antywirusowe.

David P. Caldwell
źródło
0

To samo mi się przydarzyło, rozpaczało szaleć. Po zamknięciu wielu aplikacji nic nie pomogło.

Potem zauważyłem, że jedno z okien dialogowych „Zgłoś się do Apple'a” z powodu zawieszonego procesu Pythona pozostało otwarte przez całą noc.

Choć może to być po prostu zbieg okoliczności, po zamknięciu okna dialogowego rozproszony proces uspokoił się.

Chris
źródło
0

Kilka miesięcy temu natknąłem się na podobny problem z rozproszeniem i nie mogłem wyśledzić, dlaczego użycie procesora wzrosło powyżej 100%. W końcu dodawałem wpis do mojego crontab killall distnotedco 2 minuty, co rozwiązało mój problem.

Ostatnio miałem problem z Sublime Text, w którym pisanie subl path/to/filenie otwierało się poprawnie w Sublime Editor. Ponowne uruchomienie aplikacji rozwiązało problem, ale szybko zaczęło się to powtarzać.

Po tym, jak bez końca dokuczałem mózgowi, stwierdziłem, że zabijam rozproszony proces co 2 minuty, dlaczego polecenie subl w tajemniczy sposób przestało działać.

Wniosek: bardzo wysokie użycie procesora mogło być związane z wysublimowaniem. Teraz, gdy sublime zostało zaktualizowane, mam nadzieję, że mój wniosek jest poprawny, użycie procesora pozostaje niskie, a moje polecenie subl powraca do pracy zgodnie z oczekiwaniami, teraz, gdy distnoted działa ponownie bez mojej crontab zabijającej proces co 2 minuty.

finiteloop
źródło
0

Ja też miałem ten problem od dłuższego czasu, ale sporadycznie. Najwyraźniej jest to część iTunes i spowodowało problemy również w systemie Windows . Kiedy zabiłem iTunes (który odtwarzał utwór), distontedproces, który zużywał 400% mojego procesora (mam 4 rdzenie) przestał być problemem.

Tak więc moją odpowiedzią, dopóki nie będę wiedział lepiej, jest zalecenie zabicia iTunes, a nie distnotedpoinformowanie nas, co się stanie.

vy32
źródło
-1

Widzę też rozróżnione szaleństwo, w moim przypadku wydaje się, że jest związane z fontd. Mam trzy uruchomione, jeden dla _spotlight, jeden dla _distnote i jeden dla mojego użytkownika.

distnoted   0,0 6:39,85 2   0   101 _distnote   0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit
distnoted   0,0 0,05    2   0   642 _spotlight  0 bytes 0 bytes     Yes     -   No  No  No  0 bytes 0 bytes 64 bit
distnoted   82,1    1:19:38,30  49  1   353 nils    0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit

Kiedykolwiek rozproszony zjada procesor (30-90%), fontworker i fontd zjadają około 30-60% procesora każdy. Jak tylko zabiję fontd, distnoted i fontworker dla mojego użytkownika uspokaja się. Zabijanie fontworkera nic nie robi. Po kilku minutach, gdy fontd zrestartował się i zaczął działać przez chwilę, wszystko zaczyna się od nowa.

fontworker  27,2    52,81   4   1   1073    nils    0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit
fontd   32,6    1:07,41 6   0   1072    nils    0 bytes 0 bytes     No      -   No  No  No  0 bytes 0 bytes 64 bit

Nie mam pojęcia, dlaczego tak się dzieje…

Nils
źródło
-2

Peter Buckley ma rację, mylę się. Nienawidzę tego, kiedy to się dzieje.

Nie usuwaj rozproszonego, następny rozruch nie będzie wcale zabawny.

źle> Przyjąłem bardziej młot kowalski
źle> 
źle> sudo mv / usr / sbin / distnoted /usr/bin/distnoted.unwanted
źle>
źle> To jest maszyna robocza i nie jestem zainteresowany synchronizacją z iTunes.

ConorR
źródło
To szaleństwo. Jak zauważono na stronie Apple o distnoted , distnoted jest częścią OS X, zajmuje się powiadomieniami rozproszonymi i istnieje od co najmniej 2005 roku.
jfmercer
Cokolwiek zrobisz, NIE ruszaj się, distnotedjak wspomniał ConorR (a później poprawiony, dzięki!), Wymagane jest uruchomienie OSX (10.9.5 w moim przypadku).
Peter Buckley,
Ponieważ tak naprawdę nie jest to odpowiedź, myślę, że ważne jest, aby pozostało to odnotowane gdzieś na stronie. Prawie zastanawiałem się nad próbą poruszenia z dystansem.
Zenexer