هل يستهلك peopled معالج جهاز Mac بالكامل على macOS Tahoe؟ السبب عادة هو ودجت جهات الاتصال

جهاز Mac الخاص بك دافئ دون أن يفعل شيئًا. تراجع تقدير عمر البطارية إلى النصف. تفتح Activity Monitor، ترتّب حسب استخدام المعالج، وفي الأعلى عملية لم تسمع بها من قبل — peopled — تستقر عند 70 أو 80 بالمئة وتبقى هناك. أو قد تكون contactsd. أو، في الأجهزة الأكثر تضررًا، accountsd عند 180% مع contactsd وitunescloudd خلفها. الإنهاء لا يجدي نفعًا، لأنك لا تستطيع إنهاءها. وتساعد إعادة التشغيل لمدة ساعة فقط.

تحدث هذه المشكلة لمستخدمي Mac منذ macOS Tahoe 26.4 في مارس، ولا تزال تحدث في 26.5 و26.6، ولم تعترف بها Apple بعد، والإصلاح الأكثر موثوقية غير موجود في أي من مقالات «أعد تشغيل جهاز Mac / أعد ضبط NVRAM» التي تتصدر نتائج البحث. إنه إزالة ودجت.

يشرح هذا الدليل ما هي peopled (اطّلعنا على داخلها)، ولماذا يُدخلها ودجت في حلقة لا نهائية، ولماذا تُعد علامة حجر صحي على مجلد لم تكن تعلم بوجوده هي المُحفّز الآخر، والترتيب الدقيق الذي يجب اتباعه عند تجربة الإصلاحات.

النقاط الرئيسية

• peopled هي الخدمة الخلفية (daemon) التي تقف وراء ودجت جهات الاتصال. يحتوي ملفها الثنائي على أصناف (classes) باسم WidgetSuggester وWidgetConfigurationReader وCallHistoryFetcher، وملف تعريف الحماية (sandbox) الخاص بها يمنحها صلاحية الوصول إلى قاعدة بيانات سجل مكالماتك. هذا المزيج هو سبب الحلقة اللانهائية.
• الإصلاح 1: احذف كل ودجت لجهات الاتصال — من سطح المكتب ومركز الإشعارات ومركز التحكم — ثم أعد التشغيل. حلّ هذا معظم التقارير المؤكدة البالغ عددها أكثر من 54 في منتدى مجتمع Apple.
• الإصلاح 2: امسح علامة الحجر الصحي (quarantine) عن ~/Library/Application Support/CallHistoryDB وأنهِ عملية peopled. هذا هو الحل عندما لا يوجد ودجت لحذفه؛ ويتطلب صلاحية الوصول الكامل للقرص (Full Disk Access) لتطبيق Terminal.
• الإصلاح 3: عطّل جهات اتصال iCloud ثم أعد تفعيلها. ينجح مع البعض دون الجميع، ويكلفك توقف المزامنة أثناء التعطيل.
• ارتفاعات contactsd مع حساب Exchange أو Google علة أخرى أقدم لها نفس الأعراض لكن حلّها مختلف — احذف الحساب أو استخدم تطبيق بريد من جهة خارجية.
• لم توثّق Apple أي إصلاح. لا شيء في ملاحظات إصدارات 26.4.1 أو 26.5 أو 26.6 أو 26.6.x يذكر المشكلة، والتقارير في 26.5 وما بعدها لا تزال مستمرة.

ما هي العملية بالضبط

تظهر ثلاث خدمات خلفية (daemons) في هذه التقارير وهي غير قابلة للتبادل. رتّب Activity Monitor حسب نسبة استخدام المعالج (% CPU) ولاحظ أيها لديك.

العملية	تنتمي إلى	التقرير النموذجي	السبب الأرجح
peopled	إطار عمل People — اقتراحات الودجت، Family، Screen Time، الحالة	استخدام مستمر بنسبة 70–80% منذ 26.4	ودجت جهات اتصال + تعذّر قراءة CallHistoryDB
contactsd	إطار عمل Contacts — قاعدة بيانات دفتر العناوين والمزامنة	ارتفاعات إلى 80% كل 60–90 ثانية، أو استخدام مستمر	حلقة مزامنة جهات اتصال iCloud/Exchange/Google
accountsd	إطار عمل Accounts — كل حساب مسجّل الدخول	180% إلى جانب contactsd وitunescloudd	حلقة مصادقة حساب؛ غالبًا ما يفشل حل تسجيل الخروج

إذا كانت العملية هي peopled، ابدأ بقسم الودجت. إذا كانت contactsd وحدها، انتقل إلى قسم حساب المزامنة. أما إذا كانت الثلاث معًا مع accountsd في الأعلى، فأنت في الحالة الأقل فهمًا، والقسم المخصص لها صريح بشأن مدى محدودية ما هو معروف عنها.

ما الذي تفعله peopled فعليًا

يوحي الاسم بجهات الاتصال، والأدلة التي تذكرها أصلاً تصفها بأنها «تدير بيانات جهات الاتصال». هذا صحيح تقريبًا وخاطئ من ناحية التفاصيل، والفرق هو سبب كون الحل ودجت لا إصلاحًا لدفتر العناوين.

اطّلعنا على هذه الخدمة الخلفية على جهاز Mac يعمل بإصدار 26.5.2. تقيم في /System/Library/PrivateFrameworks/People.framework/peopled، ووظيفة launchd الخاصة بها (/System/Library/LaunchAgents/com.apple.peopled.plist) تخبرك بما يوقظها. لا يتم تحميلها عند تسجيل الدخول — قيمة RunAtLoad هي false. بل يتم تشغيلها بواسطة أحداث:

• تدفقات Biome الخاصة بـ missedCall وunreadMessage وreadMessage وlocation وdndAvailability وscreenTimeRequest وaskToBuyRequest وchildState
• إشعاران من النظام: __ABDataBaseChangedByOtherProcessNotification (تغيّر دفتر العناوين) و_CalDatabaseChangedNotification (تغيّر التقويم)

إذن فكل مكالمة فائتة وكل رسالة وكل تعديل على جهة اتصال وكل تغيير في التقويم يوقظ peopled. وماذا تفعل عند استيقاظها؟ تجيب السلاسل النصية (strings) داخل ملفها الثنائي عن هذا مباشرة. من بين أسماء أصناف Swift:

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

ومن بين قوالب رسائل السجل الخاصة بها:

Event triggered widget refresh: %{private}s, %s
Last widget suggestion date is older 24 hours, suggest widgets
Last widget suggestion date is within 24 hours, do not suggest widgets
error reading widgets configurations: %s
Failed to suggest widgets with error: %s

ترتبط بإطار عمل Contacts وإطار عمل CallHistory وإطاري عمل من Biome. غرضها، بحسب ما يصفه كودها نفسه، هو تحديد الأشخاص الذين ينبغي إبرازهم في ودجت جهات الاتصال وفي الاقتراحات المتعلقة بالأشخاص، باستخدام مكالماتك ورسائلك الأخيرة كإشارة.

هذا ما يجعل نمط الفشل منطقيًا: خدمة خلفية توقظها كل مكالمة ورسالة، ومهمتها تحديث ودجت، وتحتاج لقراءة سجل المكالمات لتنفيذ ذلك.

لماذا تدخل في حلقة لا نهائية

ضع القطع من خيط نقاش المجتمع بجانب ما يقوله الملف الثنائي.

تعمل peopled داخل بيئة حماية (sandbox). ملف تعريفها، الموجود في /System/Library/Sandbox/Profiles/com.apple.peopled.sb، يبدأ بـ (deny default) ثم يفتح أبوابًا محددة. اثنان منها:

(home-subpath "/Library/CallHistoryDB/")
(home-subpath "/Library/Logs/CallHistory")

إذن يُسمح لها بقراءة ~/Library/Application Support/CallHistoryDB/، حيث يحتفظ macOS بقاعدة بيانات المكالمات الصادرة والواردة عبر جهاز iPhone الخاص بك من خلال Continuity. هذا المجلد محمي أيضًا بواسطة TCC — على جهازنا، ينتج أمر ls عليه من Terminal رسالة Operation not permitted إلى أن يحصل Terminal على صلاحية الوصول الكامل للقرص (Full Disk Access) — وهذا هو سبب حاجة الإصلاحات أدناه لهذه الصلاحية.

والآن التقارير. في 21 أبريل، اقتبس أحد المستخدمين في خيط نقاش مجتمع Apple رسالة النواة (kernel) التي وجدها في Console بينما كانت peopled تدور:

Sandbox: peopled … deny(1) file-read-data ~/Library/Application Support/CallHistoryDB

وفي 20 مايو اقتبس آخر:

failed to open /Users/[user]/Library/Application Support/CallHistoryDB: 1 (Operation not permitted)

التفسير الذي يتوافق مع كل هذا: تم تثبيت ودجت جهات اتصال، فتُطلب من peopled تحديثه؛ والتحديث يعني جلب سجل المكالمات؛ ويُرفض الجلب — لأن المجلد اكتسب سمة com.apple.quarantine، أو لسبب آخر متعلق بالصلاحيات لم تحدده التقارير بدقة — فيفشل التحديث، ثم يُطلق الحدث التالي (أو إعادة المحاولة) العملية من جديد. خدمة خلفية كان يُفترض أن تعمل لأجزاء من الثانية بعد مكالمة فائتة تعمل بدلاً من ذلك باستمرار.

نريد أن نكون دقيقين بشأن ما هو مؤكد هنا وما ليس كذلك. أسماء الأصناف وقواعد بيئة الحماية ورسائل السجل قابلة للملاحظة المباشرة؛ لقد قرأناها بأنفسنا. أما أن الحلقة هي «تحديث الودجت، رفض القراءة، إعادة المحاولة» فهذا استنتاج يتوافق مع كل تقرير رأيناه ومع كلا الإصلاحين الناجحين. لم تؤكد Apple هذه الآلية، وقد يكون هناك سبب ثانٍ للتشغيل — أبلغ أحد المستخدمين أن الحلقة بدأت بعد إعادة تنظيم مركز التحكم دون وجود ودجت جهات اتصال على الإطلاق.

تأكّد قبل أن تغيّر أي شيء

دقيقتان من الفحص توفران عليك ساعة من التخمين، ونمط استخدام المعالج يخبرك بالإصلاح الذي يجب تجربته.

راقب شكل الاستخدام. في Activity Monitor، حدد العملية وانظر إلى سجل استخدام المعالج في تذييل النافذة، أو من Terminal:

top -stats pid,command,cpu,time -o cpu -n 5

عملية peopled تستقر عند نسبة ثابتة 70–80% هي حلقة الودجت. أما contactsd التي ترتفع ثم تهبط إلى صفر ثم ترتفع مجددًا بعد دقيقة فهي حلقة المزامنة. واستخدام مستمر للمعالج في الخدمات الثلاث معًا هو حالة الحساب.

تحقق من مدة تشغيلها. تعمل peopled عادة لثوانٍ معدودة فقط. على جهازنا (السليم) ظلت مقيمة لمدة 41 يومًا بنسبة استخدام معالج 0.0% — كونها مقيمة لكن خاملة أمر طبيعي. ما تبحث عنه هو أن تكون مقيمة و نشطة في آن واحد:

ps -axo pid,etime,pcpu,comm | grep -E "peopled|contactsd|accountsd"

ابحث عن الرفض. هذا هو الاختبار الحاسم. افتح نافذة Terminal ثانية وتابع سجل الخدمة الخلفية بثًا حيًا أثناء دورانها:

log stream --predicate 'process == "peopled"' --info

وفي النافذة الأولى، ابحث في الدقائق القليلة الماضية عن سطر بيئة الحماية الذي تقتبسه تقارير المجتمع:

log show --last 10m --predicate 'eventMessage CONTAINS "Sandbox: peopled"'

إذا رأيت deny(1) file-read-data مقابل CallHistoryDB، فأنت أمام حالة CallHistoryDB والإصلاح 2 هو ما سينجح معك. إذا رأيت Event triggered widget refresh تتكرر دون رفض، ابدأ بالإصلاح 1. إذا كان السجل هادئًا واستخدام المعالج مرتفعًا، فالحلقة موجودة في كود لا يسجّل عند المستوى الافتراضي؛ جرّب الإصلاحات بالترتيب على أي حال.

راقب نظام الملفات، إن أردت اليقين. تُظهر أداة fs_usage كل عملية ملف تحاول عملية معينة تنفيذها، بما في ذلك العمليات الفاشلة:

sudo fs_usage -w -f filesys peopled

شاشة مليئة بمحاولات على CallHistoryDB تنتهي بأخطاء هي الحلقة، مرئية في الوقت الفعلي.

الإصلاح 1: احذف ودجت جهات الاتصال

هذا هو الإصلاح الذي حظي بأكبر عدد من التأكيدات، وهو الأول الذي يجب تجربته لأنه قابل للتراجع ولا يحتاج إلى Terminal.

المشكلة أن هناك ثلاثة أماكن يمكن أن يوجد فيها ودجت على جهاز Mac يعمل بـ Tahoe، ويجب أن يُحذف منها جميعًا.

سطح المكتب

اضغط بزر التحكم (Control-click) على الخلفية واختر تعديل الودجت (Edit Widgets). أي ودجت جهات اتصال على سطح المكتب يُظهر زر إزالة (علامة الطرح في الزاوية) أثناء التعديل؛ اضغط عليه. أو اضغط بزر التحكم على الودجت نفسه واختر إزالة الودجت (Remove Widget). اضغط تم (Done).

مركز الإشعارات

اضغط على التاريخ والوقت في شريط القوائم لفتح مركز الإشعارات، مرّر للأسفل، واضغط تعديل الودجت (Edit Widgets). أزل أي ودجت جهات اتصال هناك بنفس الطريقة — اضغط بزر التحكم واختر إزالة الودجت، أو اضغط زر الخيار (Option-click) على زر الإزالة الخاص به.

مركز التحكم

هذا هو الموضع الذي يفوته الناس، لأن Tahoe نقل الودجت إلى مركز التحكم والتخصيص ليس موجودًا في إعدادات النظام. اضغط على أيقونة مركز التحكم في شريط القوائم، اختر تعديل عناصر التحكم (Edit Controls)، واسحب أي عنصر جهات اتصال خارج مركز التحكم. اضغط تم (Done).

ثم أعد التشغيل — وليس مجرد تسجيل الخروج. تشير عدة إصلاحات مؤكدة في الخيط إلى أن استخدام المعالج لم ينخفض إلا بعد إعادة تشغيل كاملة.

تحذير إضافي من نفس الخيط، أُبلغ عنه في 31 يوليو: بالنسبة لبعض المستخدمين عادت الحلقة بعد فتح معرض الودجت مجددًا، حتى دون إضافة ودجت جهات الاتصال. إذا واجهت هذه المشكلة، تعامل مع محرر الودجت كشيء يجب تجنبه إلى أن تصلح Apple الخدمة الخلفية.

الإصلاح 2: امسح علامة الحجر الصحي عن CallHistoryDB

بالنسبة لأجهزة Mac التي لا تحتوي على أي ودجت جهات اتصال في أي مكان، أو التي لم تنفع فيها إزالته، فهذا هو الإصلاح الذي توصل إليه أكثر التقارير تفصيلًا من الناحية التقنية في الخيط بتاريخ 20 مايو، وأكّده مستخدمان آخران على الأقل («عملية peopled الآن عند 0% من استهلاك المعالج،» كتب أحدهم في 26 يونيو).

الخطوة 1: امنح Terminal صلاحية الوصول الكامل للقرص

إعدادات النظام > الخصوصية والأمان > الوصول الكامل للقرص (Full Disk Access)، أضف Terminal، وفعّله. بدون هذا، سيفشل كل أمر أدناه برسالة "Operation not permitted" — وهي، من قبيل المصادفة، نفس الخطأ الذي تواجهه peopled. أعد تشغيل Terminal بعد منح الصلاحية.

الخطوة 2: افحص المجلد

ls -lan@ "$HOME/Library/Application Support/CallHistoryDB"

تُظهر علامة @ السمات الموسّعة (extended attributes). ما تبحث عنه هو com.apple.quarantine على المجلد أو على ملفات CallHistory.storedata بداخله. الحجر الصحي هو العلامة التي يضعها macOS على الملفات التي يتم تنزيلها؛ ولا مبرر لوجودها على قاعدة بيانات نظام، وكيفية وصولها إلى هناك غير معروفة — الاستعادة من نسخة احتياطية والترحيل من جهاز Mac آخر هما المسارين المحتملين.

الخطوة 3: أزلها

xattr -dr com.apple.quarantine "$HOME/Library/Application Support/CallHistoryDB"

-d تحذف السمة، و-r تعمل بشكل تكراري داخل المجلد.

الخطوة 4: أعد تشغيل الخدمات الخلفية

sudo killall -9 peopled CallHistorySyncHelper

سيُعاد تشغيل كلتيهما عند الطلب. راقب Activity Monitor لبضع دقائق.

إذا عادت العلامة

أفاد أحد المستخدمين في الخيط بتاريخ 17 يوليو أن الإصلاح نجح لكن علامة الحجر الصحي «عادت للظهور» بين عشية وضحاها. إذا حدث هذا معك، فهناك شيء ما يعيد وضع الحجر الصحي على المجلد، والمرشحون هم أداة نسخ احتياطي أو مزامنة تتعامل معه كبيانات جديدة. تحقق مما يعمل ليلاً. وبطريقة أكثر حسمًا، اتّبع مستخدم آخر نهجًا يقوم على حذف قاعدة البيانات والسماح لـ macOS بإعادة إنشائها:

rm -rf ~/Library/Application\ Support/CallHistoryDB

تفقد نسخة جهاز Mac من سجل مكالماتك. تُعاد تعبئته من iPhone عبر Continuity. هذا حل أكثر جذرية من إزالة سمة واحدة، وننصح بتجربة السمة أولًا.

الإصلاح 3: بدّل جهات اتصال iCloud

إعدادات النظام > [اسمك] > iCloud > المحفوظ في iCloud > جهات الاتصال، عطّلها. انتظر دقيقة، راقب استخدام المعالج. إذا انخفض، أعد تفعيلها وانظر إن كان سيبقى منخفضًا.

ينجح هذا مع فئة من المستخدمين وهو النصيحة القياسية في الخيوط الأقدم لنفس الموضوع منذ سنوات. وله أيضًا حالة فشل واجهها أحد المستخدمين في 11 مايو: رفض المفتاح التعطل تمامًا. إذا حدث هذا، سجّل الخروج من iCloud بالكامل (مع الاحتفاظ بنسخة من البيانات عند السؤال)، أعد التشغيل، ثم سجّل الدخول مجددًا. لاحظ أن المُبلّغ على V2EX صاحب حالة accountsd جرّب هذا بالضبط وعاد استخدام المعالج فورًا بعد تسجيل الدخول.

إذا كانت العملية contactsd ولديك حساب Exchange أو Google

هذه المشكلة أقدم من Tahoe ولها آلية أوضح.

contactsd هي الخدمة الخلفية لإطار عمل Contacts: تمتلك قاعدة بيانات دفتر العناوين وتوفّق بينها وبين كل حساب يزامن جهات الاتصال. كما تقوم بأعمال صيانة مجدولة — تسجّل وظيفة launchd الخاصة بها مهمة يومية باسم validate-cache تعمل فقط عند توصيل الطاقة الخارجية وعندما تكون غير نشط، ونشاط متكرر باسم accounts.cleanup. استخدام معالج قصير وعرضي من contactsd أمر طبيعي.

ما ليس طبيعيًا هو ارتفاع كل دقيقة أو نحو ذلك. وثّق مطوّر هذا بالضبط في منتديات مطوري Apple في ديسمبر 2025: على جهاز M1 Max يعمل بـ Tahoe 26.1، أدى حساب Office 365 مفعّل فيه جهات الاتصال إلى ارتفاع AddressBookManager إلى 81% وcontactsd إلى 22–59% في نمط متكرر كل 60–90 ثانية — حتى مع تفريغ مجلد جهات اتصال Exchange على الخادم، وقابل لإعادة الإنتاج على تثبيت نظيف. نفس الحساب والبيانات لم تفعل ذلك على جهاز M4 Mac أو على iOS. لم يرد أحد من Apple.

الحل البديل الذي يعتمده هو الحل الناجح: احذف حساب Exchange من إعدادات النظام > حسابات الإنترنت (Internet Accounts)، وإذا كنت بحاجة إليه، استخدم Outlook الذي لا يمر عبر إطار عمل Contacts. تقرير من فبراير في منتدى المجتمع بخصوص contactsd على جهاز MacBook Pro طراز 2024 يعمل بـ 26.3 حصل على نصيحة مماثلة — أوقف مزامنة جهات الاتصال من Exchange وGoogle واختبر — وإذا كان لديك حساب iCloud وحساب Google يزامنان جهات الاتصال معًا، جرّب إزالة Google أولاً.

حالة accountsd

أكثر التقارير حدّة — accountsd عند 180% مع contactsd وitunescloudd يرافقانها، على جهاز MacBook Air طراز M5 يعمل بـ 26.5.2، ورد وصفها على V2EX في يوليو — ليس لها إصلاح مؤكد. لاحظ المُبلّغ أنها تبدأ في نفس الوقت كل صباح، وهو ما يشير إلى مهمة مجدولة وليس حدث ودجت. تسجيل الخروج ثم الدخول مجددًا لم يساعد.

ما يمكننا إضافته: accountsd هي الخدمة الخلفية لإطار عمل Accounts ويتم استدعاؤها كلما احتاج أي شيء إلى بيانات اعتماد لحساب مسجّل الدخول، وitunescloudd هي خدمة مكتبة iTunes Cloud (Apple Music / المتجر). ووجود الثلاثة معًا في آن واحد يعني أن شيئًا ما يطلب بيانات اعتماد الحساب بشكل متكرر ويفشل. إذا كانت لديك هذه الحالة، فلا تزال الإصلاحات أعلاه تستحق التجربة بالترتيب، وإذا لم ينجح أي منها، يستحق التحقق مما إذا كان حساب واحد — تسجيل دخول قديم لـ Google أو Exchange، أو كلمة مرور خاصة بتطبيق منتهية الصلاحية — يفشل في المصادقة ضمن إعدادات النظام > حسابات الإنترنت. أزل أي حساب يظهر عليه شارة تحذير.

لماذا Tahoe، ولماذا الودجت

الودجت موجودة على Mac منذ سنوات، لذا من المنطقي أن نسأل لماذا بدأت هذه المشكلة مع 26.4. تغيّر أمران معًا.

الأول هو مكان وجود الودجت. وضع Tahoe الودجت في مركز التحكم إلى جانب سطح المكتب ومركز الإشعارات، وودجت جهات الاتصال في مركز التحكم يُحدَّث بوتيرة مختلفة عن ذلك الموجود على سطح المكتب — قوالب السجل الخاصة بالخدمة الخلفية نفسها تميّز بين مسار يومي بعنوان «اقترح ودجت» ("Last widget suggestion date is older 24 hours") وبين تحديثات تُطلَق بواسطة الأحداث ("Event triggered widget refresh"). أسطح أكثر تعني طلبات تحديث أكثر، وفرصًا أكبر لإعادة محاولة تحديث فاشل.

الثاني هو أن معالجة الأخطاء في الخدمة الخلفية تبدو أنها تعيد المحاولة بدلاً من التراجع (back off). هذا استنتاجنا من السلوك الملاحظ، وليس شيئًا يمكننا قراءته في الملف الثنائي، وهو الخلل الفعلي: يجب تسجيل رفض القراءة مرة واحدة والتخلي عن التحديث حتى الحدث الحقيقي التالي. لكن بدلاً من ذلك تُعاد المحاولة، والأحداث لا تتوقف عن الوصول.

لا شيء من هذين الأمرين يمكنك تغييره. ما يمكنك تغييره هو ما إذا كان الودجت موجودًا وما إذا كانت القراءة مرفوضة، وهذا ما تفعله الإصلاحات الثلاثة.

بعد إصلاح المشكلة

بضعة أمور تبقيها مصلَحة.

اترك صلاحية الوصول الكامل للقرص لتطبيق Terminal كما هي إذا استخدمت الإصلاح 2، أو ألغِها عمدًا — كلاهما مقبول، لكن اعرف أيهما فعلت، لأن Terminal بصلاحية الوصول الكامل للقرص منحة واسعة.

تجنّب معرض الودجت لفترة. التقرير المؤرخ 31 يوليو في الخيط واضح في أن فتحه — وليس إضافة أي شيء — هو ما أعاد تشغيل الحلقة. إذا أردت إضافة ودجت أخرى، فافعل ذلك، ثم تحقق من Activity Monitor بعدها.

بعد تحديث macOS التالي، تحقق مجددًا. أعادت تحديثات النقاط عناصر مركز التحكم الافتراضية لبعض المستخدمين، وعودة ودجت جهات الاتصال بصمت هي السبب الأرجح لعودة المشكلة.

قدّم التقرير. Feedback Assistant، فئة macOS، أرفق تشخيص نظام (sysdiagnose) مأخوذًا أثناء ارتفاع استخدام المعالج (sudo sysdiagnose من Terminal، أو Shift-Control-Option-Command-Period)، والصق سطر رفض بيئة الحماية. خمسة أشهر من خيوط المنتدى لم تحرّك هذا الملف؛ ربما تفعل بضع مئات من تقارير Feedback التي تحمل نفس سطر السجل.

هل تم إصلاحها بعد؟

لا، على حد علم أي شخص. راجعنا ملاحظات تحديثات Tahoe من Apple: يذكر 26.4.1 أنه «يقدّم إصلاحات للأخطاء»، ويذكر 26.5 أنه «يتضمن تحسينات وإصلاحات للأخطاء وتحديثات أمنية»، ويحسّن 26.6 فهرسة Spotlight، أما 26.6.1 و26.6.2 فهما إصداران أمنيان. لا يذكر أي منها جهات الاتصال أو الودجت أو استخدام المعالج. في خيط المجتمع، تستمر التقارير على 26.5 («لا تزال المشكلة موجودة في Tahoe 26.5. تحتاج Apple لإصلاح هذا في أسرع وقت،» بتاريخ 15 مايو) وحتى يوليو. لم نرَ تقريرًا في أي اتجاه بخصوص 26.6.2 الذي صدر في 17 أغسطس.

إذا كنت تستخدم النسخة التجريبية من macOS 27 وشاهدت هذه المشكلة أو لم تشاهدها، فإن ملخص المشكلات المعروفة في النسخة التجريبية هو حيث نتابعها.

ما لا يستحق تجربته

إعادة ضبط NVRAM أو SMC. لا علاقة لأي منهما بصلاحيات ملفات خدمة خلفية على مستوى المستخدم. تجاوز هذا الخيار.

tccutil reset All. جرّبه أحد المستخدمين؛ ولم يساعد، كما أنه يزيل كل صلاحية خصوصية من كل تطبيق على الجهاز، وهو ما يجعلك تقضي بعد الظهر بأكمله في إعادة منحها. لا يوجد سبب للاعتقاد بأن TCC هي الطبقة المسؤولة عن الخلل — الرفض في السجلات هو من بيئة الحماية (sandbox)، وليس من TCC.

الوضع الآمن (Safe Mode). الإقلاع في الوضع الآمن ثم الخروج منه يمسح بعض الملفات المؤقتة (caches) ومنح بعض المستخدمين راحة مؤقتة. إنه إعادة تشغيل بخطوات إضافية ولا يعالج السبب.

تعطيل peopled باستخدام launchctl. يمكنك تنفيذ launchctl disable على هذا الوكيل (agent)، وسيتوقف عن استهلاك المعالج لأنه سيتوقف عن العمل. لكنه سيوقف أيضًا ودجت جهات الاتصال واقتراحات الأشخاص وآلية «اطلب الشراء» الخاصة بـ Screen Time وأي شيء آخر يعتمد عليه، وعلى جهاز محمي بواسطة حماية سلامة النظام (system integrity protection) قد لا يبقى هذا التغيير بعد التحديث. غير موصى به إلا كأداة تشخيص أخيرة.

استكشاف الأخطاء الشائعة وإصلاحها

يعرض Activity Monitor عشرين نسخة من contactsd

شاهدنا هذا بأنفسنا أثناء كتابة المقال: دفعة من عشرين عملية contactsd بمعرّفات عمليات (PIDs) متتالية، جميعها أبناء لـ launchd، وجميعها عند 0% من استخدام المعالج، وتختفي خلال دقيقة. هذا هو launchd يُنشئ نسخًا لكل عميل عند الطلب، وليس هو الخلل. الخلل هو عملية واحدة باستخدام معالج مرتفع تبقى قائمة.

اختفى ودجت جهات الاتصال لكن peopled لا تزال عند 80%

تحقق من المواقع الثلاثة جميعها — سطح المكتب ومركز الإشعارات ومركز التحكم — ثم انتقل إلى الإصلاح 2. إذا لم يكن لديك ودجت جهات اتصال من الأساس، انتقل مباشرة إلى الإصلاح 2.

يقول xattr "No such xattr: com.apple.quarantine"

المجلد ليس عليه حجر صحي، فهذا ليس مصدر المشكلة لديك. جرّب الإصلاح 3، وتحقق مما إذا كان لديك حساب Exchange أو Google يزامن جهات الاتصال.

يقول ls على CallHistoryDB "Operation not permitted" حتى مع sudo

لا يتجاوز sudo نظام TCC. يحتاج Terminal نفسه إلى صلاحية الوصول الكامل للقرص، مُمنوحة من إعدادات النظام، ثم يُعاد تشغيله.

عادت المشكلة بعد تحديث macOS

يمكن للتحديثات أن تعيد إضافة الودجت إلى التخطيط الافتراضي لمركز التحكم. تحقق من المواقع الثلاثة مجددًا.

الأسئلة الشائعة

هل peopled برمجية خبيثة؟

لا. إنها خدمة خلفية موقّعة من Apple، موجودة في /System/Library/PrivateFrameworks/People.framework/peopled على وحدة التخزين المختومة (sealed system volume) الخاصة بالنظام. أي عملية بهذا الاسم تعمل من مكان آخر تستحق التحقيق؛ أما هذه فهي من Apple.

هل يمكنني ببساطة إنهاؤها؟

يوقف sudo killall peopled العملية حتى يوقظها الحدث التالي، وهو ما قد يحدث خلال ثوانٍ على جهاز مشغول. إنها مفيدة كأداة تشخيص — إذا بقي استخدام المعالج منخفضًا بعد الإنهاء، فقد زال المسبب — وليست كإصلاح.

هل تفقد أي شيء عند إزالة الودجت؟

الودجت فقط. تستمر جهات الاتصال وسجل المكالمات والاقتراحات في Spotlight وMessages في العمل جميعًا؛ ولا تزال peopled تعمل عند الحاجة. إنها فقط تتوقف عن أن يُطلب منها تحديث شيء لا تستطيع تحديثه.

لماذا يحتاج مجلد CallHistoryDB إلى صلاحية الوصول الكامل للقرص لقراءته؟

يحتوي على سجل مكالماتك، الذي يعامله macOS كبيانات شخصية حساسة ويحميه بواسطة TCC مثل Messages وMail. هذه الحماية هي سبب حاجة Terminal إلى المنح، وهي أيضًا سبب كون علامة حجر صحي غير متوقعة عليه معطّلة إلى هذا الحد: تمتلك الخدمة الخلفية مسارًا واحدًا ضيقًا ومحميًا بالحماية (sandboxed) للوصول إلى البيانات، وأي شيء يحجب هذا المسار يحجبها بالكامل.

هل سيصلح macOS 27 هذه المشكلة؟

غير معروف. لم تعترف Apple بالمشكلة، ولا يوجد أي شيء في ملاحظات إصدار النسخة التجريبية بخصوصها. إذا كانت الآلية كما تشير الأدلة، فإن الإصلاح صغير — الفشل مرة واحدة والتوقف عن إعادة المحاولة — وقد يصل في أي إصدار فرعي دون أن يُذكر.

الخاتمة

جهاز Mac يعمل بحرارة دون أن يفعل شيئًا يكون غالبًا بسبب عملية واحدة عالقة في حلقة، وتلك الحلقة غالبًا ما يكون سببها أمرًا بسيطًا. في هذه الحالة، الأمر خدمة خلفية مهمتها إبقاء ودجت محدّثًا، توقظها كل مكالمة ورسالة، ولا تستطيع قراءة قاعدة البيانات الوحيدة التي تحتاجها. أزل الودجت فتتوقف الطلبات؛ أصلح صلاحيات المجلد فتنجح القراءات. كلاهما يكسر الحلقة.

إذا كانت peopled في أعلى Activity Monitor، اعمل على الإصلاحات الثلاثة بالترتيب مع إعادة التشغيل بينها. إذا كانت contactsd مع حساب Exchange أو Google، احذف الحساب. وإذا كانت الثلاثة معًا مع accountsd في المقدمة، جرّب كل ما سبق، أزل أي حساب يظهر عليه تحذير، و— لأن Apple ظلت صامتة حيال هذا لمدة خمسة أشهر — قدّم تقرير Feedback، مع سطر سجل بيئة الحماية، الذي قد يحل المشكلة أخيرًا.

قراءات ذات صلة: ارتفاع حرارة Mac واستنزاف البطارية بعد macOS 26.6، استخدام معالج WindowServer المرتفع في 26.5 مع Liquid Glass، تطبيق جهات الاتصال لا يعمل على Tahoe، دليل شامل لتطبيق Activity Monitor، وتخصيص الودجت على Tahoe.