kaçak avlanma işlemi

Bazen bir distnotedsürecin aniden dönüp,% 1.5 CPU (bir çekirdekte) ve genellikle 1.5G civarında bir semtte bir ton hafıza çiğnediğini görüyorum. Bu, bir kaç ay önce başlayan, günde birkaç kez olur.

Komut satırı , hiçbiri pek yardımcı olmadığından /usr/sbin/distnoted agentbaşlamıştır launchd. İşlemci sıkılmadan ve CPU'yu sabitlemeden önce genellikle 4 ila 24 saat arasında çalışıyor.

Web’de yapılan aramalar distnoted, bildirim teslimini yönettiğini söylüyor ve çoğu kişi de aynı sorunu bildirdiğini söylüyor , ancak henüz bir düzeltme bulamadım. Bazı insanlar bir suçlu uygulamasını kapatmanın (örn. Skype) bunu durdurduğunu fark etti, ancak makinemde henüz bir suçlu bulamadım. Genellikle sadece birkaç uygulama çalıştırıyorum: Emacs (Homebrew'den 24.2), Firefox, Adium ve Dash.

2012 sonunda Mavericks'leyim. 13 "Retina MBP. Şimdiden teşekkürler!

Güncelleme:

distnotedSistem günlüğünde oturum açarak dokunarak açtım /var/log/do_dnserver_log, ancak pek yardımcı olmuyor. Bunun gibi çizgiler görüyorum (uid 501 benim, 89 henüz bulamadım):

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.

Ayrıca sudo dtruss -p PIDbir bükülme distnotedsürecine de girdim ve bu şekilde satırlar atıyor:

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

OP'den Özet : Bu hata ayıklama için harika bir araçtır. Başlangıçta beni Spotlight'ın dosya sistemini yeniden düzenlemesine işaret etti, ancak indekslemesine izin verilen şeyleri daralttım ve hala problemi gördüm. Düzenli olarak dikkatsizleri öldürmek için bir cron işi ayarlayarak sona erdi. Cevap daha aşağıya bakın.

Dosyayı oluşturarak reddedilmiş hata ayıklama yapabilirsiniz /var/log/do_dnserver_log Bu, CFNotificationCentersunucunun ( distnoted) sistem günlüğüne tüm bildirimler hakkındaki bilgileri kaydetmesine neden olur .

Oradan başlar, yeniden başlatır ve CPU yükseldiğinde sistem günlüğüne bakardım. Bu kolayca suçlu çıkar.

CFNotificationCenterHata ayıklama hakkında daha fazla bilgiyi resmi Geliştirici belgelerinde burada bulabilirsiniz: Teknik Not TN2124> CFNotificationCenter

Bunu ben de gördüm. Emacs 24.3.1, Mavericks 10.9.

Emacs'den çıktıktan sonra, dikkatsiz sürecin saniyeler içinde sakinleştiğini buldum.

Buraya bir Emacs hatası verdim: http://permalink.gmane.org/gmane.emacs.bugs/80836

Partiye geç kaldığımı biliyorum ama bu, Mavericks'teki Cocoa emacs’e özgü bir bellek sızıntısı. Şimdilik sadece düzeltme ile emacs 24.3 oluşturmak için kullanabileceğiniz bir yama var.

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

distnotedEl Capitan'la aynı problemleri bir süredir yapıyorum . Çözümüm düzenli olarak öldürmek kadar zor değil, kontrolün bitip bitmediğini kontrol ediyorum (yüksek CPU kullanımı) ve sonra onu öldürüyorum. Bu betiği kullanıyorum:

#!/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) 
    }
    '

Komut dosyası her dakika cron'dan crontab'da bu satırla çalıştırılır:

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

Uygulamada, senaryo distnotedgünde bir veya iki kere öldürür ve genellikle bu backupdbaşlangıçtan sonra gerçekleşir .

OS X kabuğunu (komut satırı) kullanmaktan hoşlanmayanlar için, aşağıdaki komut hem checkdistnotedkomut dosyasını hem de crontab girişini yükleyecektir :

#!/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
}

Yukarıdakileri install_checkdistnoted.shmasaüstünüzdeki gibi kaydetmeniz , ardından çalıştırıp Applications/Utilities/Terminalyazmanız gerekir:

cd Desktop
sh install_checkdistnoted.sh 

Tamamen çalışırsa, adımların her birinin onayını yazdırır. Komut dosyası mevcut bir checkdistnotedkomut dosyasının veya crontab girişinin üzerine yazmaz .

Vazgeçtim ve balyoz yaklaşımını kullandım: Her dakika otomatik olarak öldür. iç çekmek.

Bunu içine koydum ~/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>

ve sonra yüklü launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

Bu davranışı daraltmak için farklı sıyırma özelleştirmeleri kombinasyonları yapıyorum; Bence bu kipli kip. Homebrew'den (veya emacsforosx'tan) gelen emaclar 24.3.1 ile 10.9'da, disnoted + emacs sızıntısı (her ikisi de bellek tüketiminde yavaş yavaş artar) bir kabuk modu tamponu açıkken gerçekleşir. Sadece dosyaları ziyaret edersen olmaz.

Sadece burada not etmek istedim, Gmane aşağı görünüyor ve bu tartışmayı haftada iki kez yaptığım araştırmada bu konuyu bulmaya devam ediyorum.

Sanırım sadece dikkatsizlerin haywire gittiği 2 durumu hatırlayabiliyorum. Bu vesileyle, bunlardan 2'si cpu listesinin başında oturuyordu ve biri% 400'den fazlaydı. Ofise döndükten ve birkaç harici ekran taktıktan kısa bir süre sonra gerçekleşti - bunlardan biri usb destekli - ilgili olabileceğini tahmin ettim. Hemen akıl sağlığına kavuşan USB ekranını çıkarmadan önce sorunu düzeltmek için başka bir şey yapmadım. Ve sonra tekrar takmak, tekrarlama problemi olmamasına neden oldu.

Hangisi neyi kanıtlar? Fikrim yok!

Onları yüzlerce kez taktım ve bu ilk kez aklıma gelebilecek aklıma geldi. Ve onları her taktığımda olmadığından, o zaman birbirlerini çok hızlı bir şekilde birbiri ardına takmakla veya bunun gibi rastgele bir şeyle ilgisi olabilir. Her neyse, başkalarının çevre birimlerine takmakla bir ilgisi olduğunu fark etmesi durumunda paylaşacağımı düşündüm (eğer harici bir ekran ise)

Bu, bir uygulama macOS tarafından sağlanan bildirim API'sini bir şekilde yanlış kullandığında ortaya çıkıyor. Benim durumumda suçlu iTerm2 idi. Bıraktıktan sonra distnotedişlemler sona erdi. Tanımlanan diğer suçlular Emacs ve iTunes'dur.

Buna değer, antivirüs yazılımımı devre dışı bırakarak bu sorunu çözebildim.

Bu da başıma geldi, dikkatsiz çıldırıyordu. Bir sürü uygulamayı kapattıktan sonra, hiçbir şeyin yardımı olmadı.

Sonra, çökertilmiş bir Python işleminden geçirilen 'Apple'a Rapor Et' iletişim kutularından birinin bütün gece açık bırakıldığını fark ettim.

Sadece tesadüf olabilir, ancak diyaloğu kapattıktan sonra, dikkatsiz süreç sakinleşti.

Birkaç ay önce reddedilmiş durumlarla benzer bir sorunla karşılaştım ve CPU kullanımının neden% 100'ün üstüne çıktığını bulamadım. Sonunda crontab'ime killall distnotedher 2 dakikada bir giriş yaptım ve bu da sorunumu çözdü.

Son zamanlarda, Sublime Text ile ilgili bir yazı yazarken subl path/to/fileSublime Editor'da yazmayı doğru bir şekilde açamadım. Uygulamanın yeniden başlatılması sorunu çözdü, ancak hızlı bir şekilde tekrar olmaya başladı.

Beynimi sonuna kadar tıklattıktan sonra, subl komutunun neden gizemli bir şekilde çalışmayı bıraktığına dair her 2 dakikada bir kayıtsız süreci öldürdüğümü belirledim.

Sonuç: Süper yüksek CPU kullanımı yüce ile ilgili olabilir. Şimdi yüce güncellendi, umarım sonucum doğrudur, CPU kullanımı düşük kalmaktadır ve subl komutum beklendiği gibi çalışmaya devam etmekte ve artık 2 dakikada crontab'ım öldürmeden ciddiyetsiz olarak tekrar çalışmaktadır.

Ben de bu sorunu yaşadım, bir süredir, ama zaman zaman. Görünüşe göre disnoted iTunes bir parçasıdır ve Windows üzerinde de sorunlara neden olmuştur . İTunes'u öldürdüğümde (bir şarkıyı çalıyordu), distontedişlemcimin% 400'ünü (4 çekirdeğim var) kullanan işlem sorun olmaktan çıktı.

Bu yüzden benim cevabım, daha iyisini öğrenene kadar iTunes'u öldürmeni tavsiye etmek değil distnoted, ne olduğunu bize bildirmek.

Ben de disnoted go haywire görüyorum, benim durumumda fontd ile ilgili görünüyor. Biri _spotlight, biri _distnote ve biri de kullanıcı için çalışan üç disnoted çalışan var.

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

Ne zaman mahsus cpu yerse (% 30-90), fontworker ve fontd her biri yaklaşık% 30-60 cpu yiyor. Fontd'yi öldürdüğümde, kullanıcılarım için dikkatsiz ve fontworker sakinleşiyor. Fontworker'ı öldürmek hiçbir şey yapmaz. Fontd yeniden başlatıldığında ve bir süredir çalıştırıldığında birkaç dakika sonra her şey yeniden başlar.

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

Bunun neden olduğu hakkında hiçbir fikrim yok…

Peter Buckley haklı, yanılmışım. Bu olduğu zaman nefret ediyorum.

Dikkatsizliği kaldırmayın, bir sonraki açılışta hiç eğlenceli olmayacak.

yanlış> daha balyoz yaklaşımı aldım
yanlış> 
yanlış> sudo mv / usr / sbin / distnoted / usr/bin/distnoted.unwanted
yanlış>
yanlış> Bu bir iş makinesi ve iTunes ile senkronize edilmeye ilgim yok.