Hva er cloudd på Mac? Forklart: iCloud Sync Daemon

cloudd er CloudKit-demonen: prosessen macOS bruker til å snakke med Apples iCloud-servere på vegne av apper. Det er en standard del av macOS, levert og kodesignert av Apple, og det er ikke skadevare.

CloudKit er Apples rammeverk for å lagre appdata i iCloud og holde dem synkroniserte på tvers av en brukers enheter. Apper åpner ikke sine egne forbindelser for å synkronisere, de overleverer dataene sine til CloudKit, og cloudd gjør jobben med å laste opp endringer, hente endringer gjort på andre enheter, og prøve på nytt ved mislykkede forespørsler.

Mer bruker det enn de fleste forventer. Synkronisering av dokumenter i iCloud Drive går gjennom det, det samme gjør Notater, og Bilder bruker det for bibliotekmetadata. Mange av Apples egne apper er avhengige av det for å holde seg synkronisert på tvers av en Mac, en iPhone og en iPad, og det gjør også mange tredjepartsapper: CloudKit er en populær synkroniseringsløsning fordi utvikleren ikke trenger en egen server.

Så når cloudd er aktiv, ser du nesten alltid iCloud-synkronisering i gang, for systemet, for en Apple-app, eller for noe du har installert.

Dette er det viktigste å forstå om cloudd, og kilden til nesten all forvirring rundt det.

cloudd er en delt budbringer. Den genererer ikke trafikk i noen meningsfull forstand; den frakter data fra andre apper. Når en notat endres, når et dokument lander i iCloud Drive, når en tredjeparts oppgavebehandler synkroniserer et element, forlater disse byteene Mac-en din under navnet til cloudd i stedet for navnet på appen som produserte dem. Verktøy som tilskriver nettverksaktivitet per prosess, inkludert Activity Monitor, vil derfor vise et stort tall mot cloudd og lite mot appene som faktisk er ansvarlige.

Så at cloudd bruker mye data er sjelden en uttalelse om cloudd. Det er en uttalelse om hvor mye appene dine synkroniserer, aggregert i én linje. To Mac-er som kjører identiske kopier av macOS kan vise store forskjeller i cloudd-tall, bare fordi den ene har et stort Photos-bibliotek og et par CloudKit-støttede apper.

macOS gjør dette også andre steder: nsurlsessiond bærer bakgrunnsnedlastinger og opplastinger for andre apper og leses som tung av samme grunn. Når du først kjenner mønsteret, slutter en travel daemon med et generisk navn å være alarmerende. Det er vanligvis en pipe, og det interessante spørsmålet er hva som blir sendt gjennom den.

cloudd er trygt. Det er en Apple-daemon fra første part, det har vært en del av macOS i årevis, og oppførselen forklares fullt ut av jobben den gjør. Den rimelige versjonen av bekymringen er ikke om den ekte cloudd er farlig, men om prosessen som kjører under det navnet på din Mac, er den ekte. Et rimelig spørsmål, siden det å ta et kjedelig navn som høres systemaktig ut er et gammelt triks.

Du kan avgjøre det uten spesialverktøy. I Aktivitetsovervåking finner du cloudd og åpner inspektøren ved å dobbeltklikke den. Den ekte demonen ligger inne på det skrivebeskyttede systemvolumet, ikke i hjemmemappen din, Programmer eller Nedlastinger, og den startes av launchd, ikke av noe du åpnet. En prosess som heter cloudd og kjører fra en brukermappe, ville være avviket verdt å undersøke.

Den sterkere sjekken er kodesignaturen. Apples systembinærfiler er signert av Apple, og på moderne macOS er systemvolumet kryptografisk forseglet, så en erstattet systemdaemon er ikke noe vanlig programvare kan ordne stille. macOS leverer kommandolinjeverktøy som rapporterer signeringsautoriteten for enhver binær, og for cloudd skal den komme tilbake som Apple.

Det er også verdt å si hva cloudd ikke er. Det er ikke en analyse- eller telemetriprosess, den flytter appdataene dine til og fra iCloud for tjenestene du allerede har aktivert.

Tung aktivitet i cloudd betyr nesten alltid at en stor synkronisering pågår, og det vanligste tilfellet er en initial. En nylig pålogget iCloud-konto, en fersk installasjon, eller en tjeneste du nettopp har slått på, må forene alt fra bunnen av, noe som kan ta timer og flytte mye data. Et stort Photos-bibliotek er det klassiske eksemplet; det samme gjelder en stor iCloud Drive-mappe som nettopp er lagt til eller gjenopprettet. Den riktige responsen er vanligvis tålmodighet: la det fullføre på en tilkobling hvor data ikke betyr noe, og aktiviteten faller tilbake til en liten drypp etter hvert.

Den andre årsaken er en synkronisering som stadig mislykkes og prøver igjen. Hvis et element ikke kan lastes opp, kan cloudd prøve igjen i en løkke, noe som ser ut som vedvarende CPU-bruk uten noe å vise til. Tegnet er aktivitet som aldri roer seg, over dager heller enn timer, uten store overføringer for å forklare det. En omstart rydder opp i en god del av disse; hvis ikke, kan det hjelpe å slå av og på den berørte tjenesten i iCloud-innstillingene, eller logge ut av iCloud og inn igjen.

Tredje, sjekk hva som faktisk er aktivert. iCloud-innstillinger viser hvilke tjenester og apper som synkroniseres, inkludert tredjepartsapper, og å slå av synkronisering for en app du sjelden bruker fjerner belastningen helt.

På en målt tilkobling er problemet ikke at cloudd er opptatt, men at det å være opptatt koster penger. Svaret er fortsatt ikke å blokkere det: sett i gang iCloud-synkronisering på pause, slå på Low Data Mode for det nettverket, deaktiver de tyngste tjenestene mens du er på det, eller begrens trafikken.

Å blokkere cloudd med en firewall er mulig, og det er en dårlig idé av én bestemt grunn: det bryter iCloud-synkronisering over hele systemet, og det gjør det stille. Ingenting viser en feil. Notater slutter å vises på dine andre enheter, dokumenter slutter å oppdatere, tredjepartsapper blir stille utdaterte, og uker senere jobber du med å finne ut hvorfor en endring gjort på din Mac aldri nådde din iPhone. Mekanismen er ikke det du skal angripe; volumet er.

Det som er det virkelige problemet: synlighet. macOS kjører mange daemons som snakker med nettverket uten å spørre, de fleste med navn som ikke avslører noe, og tilbyr nesten ingen måte å se hvilke som kobler til hvor eller hvor mye de overfører. Når én dukker opp øverst på en båndbredde-liste, finnes det ingen innebygd måte å vurdere om det er normalt.

Det gapet er det NetMute dekker. Det viser sanntids trafikk per app og per prosess, og domenenivå-logging registrerer hvilke domener hver prosess kontaktet og hvor mye data som gikk med. For målt bruk er per-app datagrense det praktiske verktøyet: en daglig eller månedlig grense per prosess, en advarsel ved en terskel du velger, og en automatisk blokkering ved 100 prosent, med en global grense øverst og grenser lagret per nettverksprofil, slik at hotspot-reglene dine ikke er de samme som hjemmereglene. Profilene byttes automatisk med Wi-Fi-nettverket du kobler til, og per-app-firewallen blokkerer alt som ikke skal snakke med ett klikk, med selvutløpende midlertidige regler for testing.

Målet er ikke å blokkere mer. Som cloudd viser, er mesteparten av bakgrunnstrafikken på en Mac legitim. Målet er å kunne skille mellom dem, og å holde det innenfor et budsjett når tilkoblingen du bruker har det.