processo zsh prendendo il 95% della mia CPU

Quando apro il mio monitor attività, ho un processo zsh che prende tutta la mia CPU. È normale? Ho iTerm e oh-my-zsh installati ma non mi aspetto un comportamento normale.

Qualche idea?

macos zsh

— Martin Delille
fonte

È riproducibile per ogni nuova sessione di zsh? In tal caso, iniziare senza file zshrc e restringere il problema. O è solo un processo che è impazzito?

— mpy,

Ho riavviato il mio sistema e il processo non era più qui. Appare di nuovo una volta avviato iTerm ma con CPU molto bassa (0,25%).

— Martin Delille,

Questo è un duplicato di un'altra domanda apple.stackexchange.com/questions/146919/… .

— Alex Palcuie,

Anche io incontro questo problema. Implica sempre installd, e soprattutto, l' installdinstallazione / l'aggiornamento di app Apple, come iWork (IIRC è esclusiva di iWork; almeno devo ancora imbattermi in un'app di terze parti).

Credo che non abbia nulla a che fare con iTerm2 o oh-my-zsh (anche se io uso entrambi). Quello che credo è che questo è un problema di compatibilità della shell - lo script di installazione di Apple chiama probabilmente la shell predefinita

$SHELL -c command...

È stato testato bashma non zsh, quindi quando zshviene chiamato in questo modo, sorgono sottili problemi di compatibilità della shell. Quando controlli il processo offensivo (purtroppo Activity Monitor, AFAIK, non ti mostra i comandi completi; io lo uso htopper questo e potresti usare pso altro), vedrai cose come

zsh -c defaults delete com.apple.helpd com.apple.helpd.sdmMapsCreated

che sostiene la mia ipotesi (beh, la mia ipotesi è stata effettivamente derivata da queste osservazioni, per essere precisi). * Pertanto, la soluzione è semplicemente eseguire il comando da soli, in questo caso

defaults delete com.apple.helpd com.apple.helpd.sdmMapsCreated

Quindi uccidi i processi offensivi. installdpassa automaticamente (probabilmente al prossimo processo bloccato come questo). Dopo più turni di rettifica, l'installazione verrà completata correttamente. So che questo è fastidioso, ma questo è l'unico modo in cui ho scoperto di funzionare (in modo affidabile).

* In realtà è al di là di me come zsh -crimane bloccato su cose come defaults delete. Non sono sicuro se è con il mio ambiente. (Ho messo i coreutils GNU e simili di fronte alle cose di BSD nel mio PERCORSO, ma sono abbastanza sicuro di non aver mai fatto casini default.) Forse defaultusi internamente i programmi di utilità BSD? Ma ancora una volta, posso eseguire lo stesso comando nel mio terminale con zsh, in modo interattivo o non interattivo, bene. Questo è davvero sconcertante (la soluzione sopra non è interessata). Qualsiasi input è il benvenuto.

— 4ae1e1
fonte

Che bella analisi! Grazie mille ci proverò non appena il problema si ripresenterà :-)

— Martin Delille,

Il problema non si è più verificato ma ho davvero apprezzato il tuo aiuto!

— Martin Delille,

Grazie per i suggerimenti! Per mostrare l'intera riga di comando del processo con lo psstrumento standard , esegui semplicemente ps uaxwww | grep zsh: 1. controlla cosa sta controllando la CPU; 2. eseguirlo manualmente; 3. uccidere il processo; 4. ripeti

— Cyber Oliveira

L' -canalisi di compatibilità suona bene, anche se non riesco a capire perché sia rimasto bloccato, invece di fallire e tornare. Sto provando a riprodurlo da solo. Da dove hai installato i coreutils GNU? E per caso stai usando un Homebrew o altri non predefiniti zsh?

— Andrew Janke,

@AndrewJanke Non so perché, e penso che probabilmente uno dovrebbe leggere gli script del pacchetto per capire, cosa che non mi sono mai preoccupato di fare. Il mio coreutils proviene da Homebrew (MacPorts ai tempi), e il mio Zsh è stato lo Zsh di serie per la maggior parte (di recente sono passato alla versione 5.0.7, ma il problema qui è stato risolto molto prima).

— 4ae1e1,

Ho regolarmente lo stesso problema ed è sempre correlato al processo installd, l'aggiornamento di un'applicazione AppStore. Uccidere prima installd e poi il processo zsh aiuta (ma disabilita la funzionalità dell'AppStore fino al riavvio).

— RBQ
fonte