Co to jest proces „secd”?

19

Zastanawiam się, co secdrobi proces w OSX Yosemite. Jestem prawie pewien, że widziałem ten proces działający we wcześniejszych wersjach MacOS, ale nie pamiętam, aby pochłaniał całą dostępną pamięć tak odważnie ...

Mam trzy komputery z systemem Yosemite, każdy z inną konfiguracją. Wszystkie trzy były aktywne przez okres od trzech dni do jednego tygodnia. Oto podsumowanie tego, secdco udało się osiągnąć:

  • Na MacBookAir 2011 z 4 GB pamięci, przydzielono 700 MB secd
  • Na komputerze iMac 2008 z 6 GB pamięci 2 GB zostało przydzielone secd
  • Na komputerze iMac 2011 z 12 GB pamięci przydzielono 4 GB secd

Na wszystkich trzech komputerach secdjest największy proces w pamięci (większy niż kernel task) i podejrzewam, że odgrywa on rolę w spowolnieniu, którego ostatnio doświadczyłem wraz z pojawieniem się Yosemite. Wiem na pewno, że proces rozszerza się w pamięci do nadmiernych rozmiarów i zwalnia pamięć, gdy potrzebuję jej gdzie indziej. Jedynym problemem jest to, że zwalnianie pamięci nie jest tak szybkie i przez większość czasu wydajność spada, zanim proces zda sobie sprawę, że musi się wycofać.

Moje wyszukiwanie w Internecie nie doszło do jednoznacznego wniosku co do tego, jaki jest proces i dlaczego powinien być tak ogromny. Chyba nie jestem jedynym, który tego doświadcza. Każda wskazówka jest mile widziana.

Jak sugerowano poniżej secd, dotyczy to pęku kluczy Apple. Oto pliki i porty, które proces utrzymuje otwarty, gdy jest aktywny (na MacBookAir):

/
/usr/libexec/secd
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-shm
/usr/share/icu/icudt53l.dat
/usr/lib/dyld
/private/var/run/diagnosticd/dyld_shared_cache_x86_64
/dev/null
/dev/null
/dev/null
count=2, state=0x2
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-shm
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal
/dev/random
/dev/random
/private/var/folders/z_/806bzc396cxgp4s0q17tpfwc0000gn/T/etilqs_y5BDgkbGkBV9ybF
/private/var/folders/z_/806bzc396cxgp4s0q17tpfwc0000gn/T/etilqs_Aw6Q7JhPlil3QNX
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal

Nie jest jasne, co ten proces robi z całą zajmowaną pamięcią i dlaczego tak bardzo się powiększa.

macos mavericks yosemite memory daemons retrografia
źródło
2
Twoja pamięć jest właściwa. secddziała na Mavericks. Przy szybkiej analizie ten demon nie jest udokumentowany, to źle, może to być kawałek crapware. Ten demon jest włączony /usr/libexec/secd.
dn
@danielAzuelos Czy wykazuje to samo zachowanie rakowe u Mavericks?
retrografia
2
Według Plist secd służy do zarządzania pękiem kluczy w chmurze, a nie lokalnym.
Ruskes,
2
Właśnie odkryłem: bez secduruchamiania Wiadomości za każdym razem pytają mnie o hasło.
ciekawe,
1
→ Mah: w Maveriskc secdma VSZ = 2,4 GB i RSS = 3 MB. secddziałał przez 84 s w systemie, który działa od 5 dni.
dan

Odpowiedzi:

20

Jeśli nie jest to oczywiste, to tylko przypuszczenie. Ale miejmy nadzieję, że daje to kilka wskazówek.

Po pierwsze, oto, co możesz dowiedzieć się tylko z nazwy programu. Jeśli uruchomić polecenie /bin/ls /usr/libexec | sort -f | egrep '.*d$'(to wydrukować wszystkie pliki /usr/libexeckończące się d), przekonasz się ftpd, hidd, networkd, systemstatsd, a wiele programów kończących się d. „D” oznacza „demon”, co w zasadzie oznacza proces pomocniczy, który zawsze działa w tle. secStoi bardzo prawdopodobne dla „bezpieczeństwa”. Podobnie secdjest z „demonem bezpieczeństwa”. Ma to sens, ponieważ powiedziałeś, że wygląda to tak, jakby działało z pękiem kluczy.

Jaki jest sens demonów? Niektóre demony pozostają uruchomione, aby wykonać jakieś bieżące zadanie. hidd(„demon urządzenia interfejsu człowieka”), na przykład, jest procesem odpowiedzialnym za obsługę danych wejściowych myszy / klawiatury / gładzika. Niektóre inne demony wykonują niektóre typowe zadania, których potrzebuje wiele innych programów. Aplikacje mogą po prostu powiedzieć demonowi, aby coś zrobił, zamiast mieć kod do zrobienia tego sam. Więc secdprawdopodobnie robi coś takiego, ale związane z pęku kluczy.

Ale co dokładnie? Wygląda na to, że tak naprawdę nie obsługuje normalnego używania pęku kluczy, ponieważ nadal byłem w stanie używać pęku kluczy po wyłączeniu secdLaunchAgent.

Sprawdzanie LaunchAgent daje nam wskazówkę:

Wygląda na to, że secd jest odpowiedzialny za synchronizację pęku kluczy z iCloud?

Co powinieneś zrobić? Wypróbuj jedną lub więcej z tych opcji:

  1. Jeśli nie potrzebujesz synchronizacji pęku kluczy iCloud, wyłącz ją w preferencjach iCloud.
  2. Użyj, launchctlaby wyłączyć secd, jeśli wydaje się, że nie ma to żadnego negatywnego wpływu.
  3. Jeśli potrzebujesz synchronizacji pęku kluczy iCloud, sprawdź, czy masz mnóstwo elementów pęku kluczy i usuń te, których nie potrzebujesz.
  4. Być może odbuduj swój breloczek (utwórz nowy brelok, przenieś do niego potrzebne elementy i przesuń go nad starszym), na wypadek, gdyby w starym breloku pozostały niepotrzebne artefakty.
co ciekawe
źródło
To niesamowity szczegół. Krok 2 powinien zawierać gwiazdkę - zwróć uwagę, że to wyłączyłeś, ponieważ Apple zwykle dodaje do tego nową funkcję, a Mac się zepsuje, gdy to się stanie, więc pamiętaj, aby od czasu do czasu włączyć ją ponownie i powrócić do decyzji o wyłączeniu demon systemowy.
bmike
Znowu - fantastyczna odpowiedź, która wyjaśnia, jak przebudować dowolnego demona, a nie tylko tego, który nie jest dobrze udokumentowany.
bmike
5

Program / usr / libexec / secd jest dostarczany jako część systemu OS X i jest normalnym procesem bezpieczeństwa. Dokumentacja mówi, że odnosi się do „zasad bezpieczeństwa środowiska wykonawczego dla procesów”. Możesz sprawdzić powiązane procesy za pomocą tego polecenia:ps -ef|grep sec[iud]

Na komputerze Mac jestem użytkownikiem 501, więc masz dane wyjściowe dla jednego zalogowanego użytkownika:

Mac:~ bmike$ ps -ef|grep sec[iud]
    0    58     1   0 Sat12PM ??         0:56.51 /usr/sbin/securityd -i
    0   117     1   0 Sat12PM ??         0:00.15 /usr/libexec/secinitd
    0   171     1   0 Sat12PM ??         0:02.24 /usr/libexec/securityd_service
  501   205     1   0 Sat12PM ??         0:11.74 /usr/libexec/secinitd
  501  2634     1   0 Tue08PM ??         0:08.26 /usr/libexec/secd

Możesz zobaczyć, że securitydjest uruchamiany jako root (PID 58), a następnie jako proces użytkownika (PID 205) podczas logowania. Rzeczywiste secdwykonuje „pracę” i może zostać odrodzone, nawet jeśli się nie wylogujesz i nie zalogujesz. Jako aby odszyfrować, dlaczego twój używa dodatkowych zasobów, będzie to dość trudne bez zagłębiania się fsusagei innych poleceń do podglądania uruchomionych procesów, a także przeglądania plików dziennika. Najlepszym rozwiązaniem byłoby zgłoszenie błędu do Apple, a następnie udokumentowanie, w jaki sposób można go źle zachować - zwłaszcza jeśli można go odtworzyć po ponownym uruchomieniu.

Obecnie nie ma „strony secdpodręcznika ” dla, a ta dla secinitdjest w najlepszym razie skromna. Zgłaszanie błędów w dokumentacji przeciwko Apple to jeden ze sposobów na zażądanie usunięcia braku dokumentacji.

bmike
źródło
3

Z tego, co wiem o tym procesie (który tak naprawdę nie jest toną), jest to, że ma on coś wspólnego z pękiem kluczy Maca. Co możesz zrobić, to znaleźć w monitorze aktywności i kliknąć Cmd + I, aby uzyskać informacje na ten temat.

Jedną wskazówką, którą możesz spróbować zrobić, jest uruchomienie pierwszej pomocy pęku kluczy, przechodząc do dostępu do pęku kluczy w Spotlight, otwierając menu „Dostęp do pęku kluczy”, a następnie wybierając opcję „Pierwsza pomoc pęku kluczy” i postępując zgodnie ze wskazówkami.

Mam nadzieję, że ta wskazówka zadziała!

jaller200
źródło
Brelok Pierwsza pomoc mówi, że mój brelok jest w porządku! Na wszystkich trzech komputerach.
retrografia
Dostępna jest opcja w El Capitan (przynajmniej może występować również w poprzednich wersjach) w obszarze Dostęp do pęku kluczy - Preferencje resetowania domyślnego klucza „Przywraca domyślne ustawienia fabryczne i tworzy nowy pusty pęku kluczy„ login ”. Twój obecny domyślny pęku kluczy będzie zostać przeniesione na bok, ale nie usunięte ”. Jak tylko to zrobiłem, securityd_service przeszedł z 51-53% procesora do 0-1,5%. Jak tylko to zrobisz, musisz ponownie zalogować się do iCloud - jeszcze nie odkryłem innych konsekwencji.
Oskar Austegard,
1
Właśnie uaktualniłem z Mavericks do Sierra i odkryłem, że drugi procesor przeszedł z prawie 100% po zresetowaniu pęku kluczy, jak sugerowałeś. Zgubiłem wszystkie zapisane hasła do witryny, musiałem ponownie zalogować się do synchronizacji kalendarza itp., Ale przynajmniej mogę ponownie użyć komputera. Dzięki.
Walter Nissen