niekontrolowany rozproszony proces

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
...

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

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

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

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.

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.

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.

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)

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.

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

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ę.

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.

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.

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…

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.