quá trình bỏ trốn

Đôi khi tôi thấy một distnotedquá trình đột nhiên quay lên và nhai CPU 100% (trên một lõi) và một tấn bộ nhớ, thường ở vùng lân cận 1,5G hoặc hơn. Điều này xảy ra một vài lần một ngày, bắt đầu từ một tháng trước.

Dòng lệnh là /usr/sbin/distnoted agent, và nó bắt đầu bởi launchd, không cái nào giúp được nhiều. Nó thường được chạy trong khoảng từ 4h đến 24h trước khi nó quay vòng và chốt CPU.

Các tìm kiếm trên web cho biết distnotedquản lý việc gửi thông báo và rất nhiều người khác báo cáo vấn đề tương tự với nó, nhưng tôi vẫn chưa tìm ra cách khắc phục. Một số người thấy rằng việc đóng ứng dụng thủ phạm (ví dụ Skype) sẽ dừng ứng dụng đó, nhưng tôi chưa tìm thấy thủ phạm trên máy của mình. Tôi thường chỉ chạy một vài ứng dụng: Emacs (24.2 từ Homebrew), Firefox, Adium và Dash.

Tôi đang tham gia Mavericks vào cuối năm 2012 13 "Retina MBP. Cảm ơn trước!

Cập nhật:

Tôi đã bật distnotedđăng nhập vào nhật ký hệ thống bằng cách chạm /var/log/do_dnserver_log, nhưng nó không giúp được gì nhiều. Tôi thấy những dòng như thế này (uid 501 là tôi, 89 tôi chưa tìm thấy):

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.

Tôi cũng đã chạy sudo dtruss -p PIDtrên một distnotedquy trình kéo dài và nó tạo ra các dòng như thế này:

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

Tóm tắt từ OP : Đây là một công cụ tuyệt vời để gỡ lỗi. Nó ban đầu chỉ cho tôi Spotlight giới thiệu lại hệ thống tập tin, nhưng tôi đã thu hẹp những thứ được phép lập chỉ mục và tôi vẫn thấy vấn đề. Tôi đã kết thúc việc thiết lập một công việc định kỳ để tiêu diệt thường xuyên. Xem câu trả lời xa hơn.

Bạn có thể gỡ lỗi bằng cách tạo tệp /var/log/do_dnserver_log Điều này khiến CFNotificationCentermáy chủ ( distnoted) ghi thông tin về tất cả các thông báo vào nhật ký hệ thống.

Tôi sẽ bắt đầu ở đó, khởi động lại và xem nhật ký hệ thống khi CPU tăng đột biến. Điều này nên ra thủ phạm dễ dàng.

Thông tin thêm về CFNotificationCentergỡ lỗi có thể được tìm thấy trong các tài liệu chính thức của Nhà phát triển tại đây: Lưu ý kỹ thuật TN2124> CFNotificationCenter

Tôi cũng đã thấy điều này. Emacs 24.3.1, Mavericks 10.9.

Tôi đã thấy rằng quá trình phân biệt đã bình tĩnh trong vài giây sau khi tôi rời khỏi Emacs.

Tôi đã gửi một lỗi Emacs tại đây: http://permalink.gmane.org/gmane.emacs.bugs/80836

Tôi biết tôi đến bữa tiệc muộn nhưng đây là một vụ rò rỉ bộ nhớ dành riêng cho ca cao của ca cao trên Mavericks được cố định trong cốp xe. Hiện tại có một bản vá bạn có thể sử dụng để xây dựng emacs 24.3 chỉ với bản sửa lỗi.

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

Tôi đã gặp vấn đề tương tự với distnotedEl Capitan một thời gian. Giải pháp của tôi không gay gắt bằng việc giết nó thường xuyên, thay vào đó tôi kiểm tra xem nó có mất kiểm soát không (sử dụng CPU cao), và sau đó giết nó. Tôi sử dụng tập lệnh này:

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

Kịch bản được chạy từ cron mỗi phút với dòng này trong crontab:

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

Trong thực tế, tập lệnh giết chết distnotedmột hoặc hai lần một ngày và thông thường, điều này xảy ra sau khi backupdbắt đầu.

Đối với những người không thoải mái với việc sử dụng shell OS X (dòng lệnh), tập lệnh sau sẽ cài đặt cả checkdistnotedtập lệnh và mục 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
}

Bạn cần lưu ở trên như install_checkdistnoted.shtrên máy tính để bàn của bạn, sau đó chạy Applications/Utilities/Terminalvà gõ:

cd Desktop
sh install_checkdistnoted.sh 

Nếu nó hoạt động đầy đủ, nó sẽ in xác nhận của từng bước. Tập lệnh sẽ không ghi đè lên checkdistnotedtập lệnh hiện có hoặc mục crontab.

tôi đã từ bỏ và thực hiện phương pháp búa tạ: tự động giết nó, mỗi phút. thở dài.

tôi đặt cái này vào ~/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>

và sau đó cài đặt nó với launchctl load ~/Library/LaunchAgents/org.snarfed.pkill_distnoted.plist.

Tôi đã thực hiện các kết hợp khác nhau của các tùy chỉnh tước để thu hẹp hành vi này; Tôi nghĩ đó là chế độ comint. Vào ngày 10.9 với emacs 24.3.1 từ homebrew (hoặc từ emacsforosx), rò rỉ + emacs bị phân tán (cả hai đều tăng chậm tiêu thụ bộ nhớ) sẽ xảy ra khi mở một bộ đệm chế độ shell. Nó sẽ không nếu bạn chỉ truy cập các tập tin.

Chỉ muốn lưu ý nó ở đây, gmane dường như không hoạt động và tôi tiếp tục tìm thấy cuộc thảo luận này trong hai lần tìm kiếm hàng tuần của tôi để theo dõi vấn đề này.

Tôi nghĩ rằng tôi chỉ có thể nhớ 2 lần mà sự phân biệt đã đi haywire. Nhân dịp này, có 2 người trong số họ đứng đầu danh sách cpu và một người chiếm hơn 400%. Nó đã xảy ra ngay sau khi trở lại văn phòng và cắm một vài màn hình bên ngoài - một trong số đó là nguồn USB - tôi đoán rằng nó có thể liên quan. Tôi không làm gì khác để thử và khắc phục sự cố trước khi rút màn hình USB ra, điều đó mang lại sự tỉnh táo ngay lập tức. Và sau đó cắm lại dẫn đến không có vấn đề lặp lại.

Điều đó chứng tỏ điều gì? Không ý kiến!

Tôi cắm chúng hàng trăm lần và đây là lần đầu tiên nó xảy ra với tôi rằng nó có thể liên quan. Và vì nó không xảy ra mỗi khi tôi cắm chúng, nên nó có thể có liên quan đến việc cắm cả hai vào nhau quá nhanh, hoặc một cái gì đó ngẫu nhiên như thế. Dù sao tôi nghĩ tôi sẽ chia sẻ trong trường hợp người khác thấy nó có liên quan gì đến việc cắm các thiết bị ngoại vi (nếu đó là màn hình bên ngoài)

Điều này dường như xảy ra khi một ứng dụng bằng cách nào đó sử dụng sai API thông báo do macOS cung cấp. Trong trường hợp của tôi, thủ phạm là iTerm2. Sau khi bỏ nó, các distnotedquá trình thoát ra. Thủ phạm khác đã được xác định là Emacs và iTunes.

Để biết giá trị của nó, tôi đã có thể khắc phục sự cố này bằng cách vô hiệu hóa phần mềm chống vi-rút của mình.

Điều này cũng xảy ra với tôi, bị làm phiền là phát điên. Sau khi đóng một loạt các ứng dụng, không có gì giúp được.

Sau đó, tôi nhận thấy một trong những hộp thoại 'Báo cáo với Apple' từ quy trình Python bị lỗi đã bị bỏ ngỏ suốt đêm.

Mặc dù nó chỉ có thể là trùng hợp ngẫu nhiên, sau khi đóng hộp thoại, quá trình phân biệt được làm dịu đi.

Tôi đã gặp phải một vấn đề tương tự với sự phân biệt một vài tháng trước và không thể theo dõi lý do tại sao việc sử dụng CPU lại tăng vọt trên 100%. Cuối cùng, tôi đã thêm một mục vào crontab của tôi killall distnotedcứ sau 2 phút giải quyết vấn đề của tôi.

Gần đây, tôi gặp sự cố với Sublime Text khi gõ subl path/to/filekhông thể mở tệp chính xác trong Trình chỉnh sửa tuyệt vời. Việc khởi động lại ứng dụng đã khắc phục sự cố, nhưng nó nhanh chóng bắt đầu xảy ra lần nữa.

Sau khi làm hỏng bộ não của tôi đến tận cùng, tôi xác định thực tế là tôi đã giết quá trình bị phân tán cứ sau 2 phút để giải thích tại sao lệnh subl lại ngừng hoạt động một cách bí ẩn.

Kết luận: việc sử dụng CPU siêu cao có thể liên quan đến siêu phàm. Bây giờ, sự siêu phàm đã được cập nhật, hy vọng kết luận của tôi là chính xác, việc sử dụng CPU vẫn ở mức thấp và lệnh subl của tôi trở lại hoạt động như mong đợi khi mà distnoted đang chạy lại mà không cần crontab của tôi giết quá trình cứ sau 2 phút.

Tôi cũng đã có vấn đề này, trong một thời gian khá lâu, nhưng không liên tục. Rõ ràng bị phân tán là một phần của iTunes và cũng đã gây ra sự cố trên Windows . Khi tôi giết iTunes (đang phát một bài hát), distontedquá trình sử dụng 400% CPU của tôi (tôi có 4 lõi) đã ngừng hoạt động.

Vì vậy, câu trả lời của tôi, cho đến khi tôi biết rõ hơn, là khuyên bạn nên giết iTunes chứ không phải distnotedcho chúng tôi biết điều gì xảy ra.

Tôi cũng thấy phân biệt đi haywire, trong trường hợp của tôi nó có vẻ liên quan đến fontd. Tôi có ba lần chạy phân tán, một cho _spotlight, một cho _distnote và một cho người dùng của tôi.

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

Bất cứ khi nào phân biệt ăn cpu (30-90%), fontworker và fontd ăn khoảng 30-60% cpu mỗi cái. Ngay khi tôi giết fontd, distnot và fontworker cho người dùng của tôi bình tĩnh lại. Giết chết fontworker không làm gì. Sau một vài phút khi fontd đã khởi động lại và đang chạy một lúc thì tất cả bắt đầu lại.

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

Tôi không biết tại sao chuyện này lại xảy ra

Peter Buckley đúng, tôi sai. Tôi ghét nó khi điều đó xảy ra.

Đừng xóa bỏ, lần khởi động tiếp theo sẽ không vui chút nào.

sai> Tôi đã thực hiện một cách tiếp cận búa tạ hơn
sai> 
sai> sudo mv / usr / sbin / distnoted /usr/bin/distnoted.unwocate
sai>
sai> Đây là một máy làm việc và tôi không có hứng thú với việc đồng bộ hóa với iTunes.