Il mese 13 è fuori dai limiti?

Questo errore viene registrato su iOS 11 e su macOS 10.13 di sicuro e non vedo che causi alcuna funzione o problema specifico su alcuna piattaforma.

Collegherò alla domanda principale qui a proposito di "macOS registro troppo" dal momento che è un'opinione e un'impressione degne di essere discusse. Alcune persone potrebbero sentirsi meglio se non ci fossero messaggi a meno che una condizione veramente seria abbia bisogno di azione. Altri vogliono ancora più dettagli in modo che possano sapere cosa sta succedendo / impara / misura. Quindi, sarà un compromesso su come questi sono problemi / categorizzati / utilizzati.

• Fresh installazione macOS: Console.app visualizza errori / errori. È normale?

Uno sviluppatore interessante che ha alcuni strumenti è Howard Oakley che scrive blog su link

La sua pagina di download ha due app di interesse (utilizza il link di download a sinistra in quanto le versioni di prodotto di seguito sono beta e potrebbero non essere aggiornate in un giorno o settimana):

• Consolazione - un browser di console alternativo
• Woodpile - uno strumento per contare / bin / analizzare i modelli di registrazione

Posso verificare la legittimità di questo problema. Ho avuto lo stesso problema ieri, e dopo un riavvio, il computer è stato reso quasi inutile a causa di questo errore. Per qualche ragione, il computer non può gestire questo mese e genera errori ovunque ci siano database o plists.

Per risolvere questo problema:

1. Apri Activity Monitor e forza la chiusura di due processi: lsd , UserEventAgent

2. Apri le Preferenze di Sistema e vai a "Data e ora"

3. Deseleziona "Imposta data e ora automaticamente"

4. Nel calendario, seleziona una data prima di dicembre 2017 e premi Salva

5. Se UserEventAgent o lsd continuano a causare problemi, quindi forza di chiuderli di nuovo dopo aver impostato la data.

Altre persone hanno questo problema

Perché?

Mi sembra che UserEventAgent stia tentando di utilizzare due file plist:

System/Library/LaunchAgents/com.apple.UserEventAgent-Aqua.plist

e

System/Library/LaunchAgents/com.apple.UserEventAgent-LoginWindow.plist

Quando ha provato a utilizzare i plists, ha ottenuto un errore:

Month 13 is out of bounds

Non sono sicuro di cosa sia effettivamente accaduto all'interno di UserEventAgent, ma è ovvio che quando riceve l'errore, non può gestirlo e causa un elevato utilizzo di CPU e RAM.

Ho riscontrato lo stesso problema con la CPU UserEventAgent estremamente elevata e l'utilizzo della memoria a partire da dicembre 2017. La console mostrava l'errore "mesi oltre i limiti" come descritto sopra.

Ho provato l'utilità del disco "pronto soccorso", riavvio, modalità sicura (per cancellare la cache di sistema), la rimozione di NVRAM e SMD, non ha aiutato. Ho notato che l'utilizzo della CPU e della memoria non ha raggiunto il picco in modalità sicura.

Come @tgray e u / kidtexas , ad un certo punto ho capito che se avessi disabilitato tutti i miei plist di avvio personalizzati che il problema non si fosse verificato.

Alla fine ho scritto il piccolo script qui sotto per aiutarmi a eseguire il debug di quale plist stava causando il problema. Finì per essere un plist che viene eseguito il primo di ogni mese:

<key>StartCalendarInterval</key>
<dict>
    <key>Day</key>
    <integer>1</integer>
    <key>Hour</key>
    <integer>03</integer>
    <key>Minute</key>
    <integer>00</integer>
</dict>

Molti dei miei plists usano la chiave StartCalendarInterval , e usando lo script qui sotto ho potuto mostrare che non sembravano causare problemi di RAM e di memoria, quindi non è del tutto chiaro me perché uno specifico plist causa il problema. Indipendentemente da ciò, ho risolto il problema.

I strongmente consiglia ai lettori di guardare attraverso lo script per cercare di capire cosa fa invece di copiare e incollare. Specificamente, come scritto, funzionerà solo per i plists in ~/Library/LaunchAgents (non /Library/LaunchDaemons e altri) e testerà intenzionalmente solo i plists il cui nome file e <key>Label</key> seguano il modello specifico: com.USERNAME.my_plist_name[.plist] . Prima di eseguirlo, ho utilizzato un one-liner in bootout di tutti i miei plists: for plist in com."$(whoami)".*.plist; do launchctl bootout gui/"${MYUID}"/"${plist%.plist}" || true; done , quindi ho verificato che non comparissero più sotto launchctl list results.

#! /bin/bash
# https://apple.stackexchange.com/questions/307512/month-13-is-out-of-bounds

set -euf -o pipefail

MYUID="$(id -u)"

pushd "${HOME}"/Library/LaunchAgents

while IFS= read -r -d '' plist; do
  echo "${plist}"
  stats=($(ps ux | grep -v grep | grep UserEventAgent | awk '{ print $3, $5}'))
  cpu="${stats[0]}"
  vmem="${stats[1]}"
  echo "CPU use and virtual memory size while disabled: ${stats[@]}"
  launchctl bootstrap gui/"${MYUID}" "${plist}"
  sleep 5
  stats=($(ps ux | grep -v grep | grep UserEventAgent | awk '{ print $3, $5}'))
  echo "CPU use and virtual memory size while enabled: ${stats[@]}"
  echo "Change in vmem: $(( "${vmem}" - "${stats[1]}" ))"
  echo
done < <(find . -iname "com.$(whoami).*.plist" -print0)

popd

Come gli altri, avevo un elevato utilizzo della CPU e un enorme utilizzo della RAM da parte di UserEventAgent (vedi il mio commento sopra). Cambiare la data a novembre e forzare la chiusura di UserEventAgent risolti. Tutto è iniziato sabato dopo il riavvio.

Fix

L'ho capito per me. Se tutto va bene per gli altri con problemi, questo funzionerà per te.

Il problema era un plist LaunchAgent che ho in ~ / Library / LaunchAgents. È un semplice file plist che chiama StartCalendarInterval, che è una chiave valida per i plists di launchd. Il processo LaunchAgent chiama uno script di shell che copia alcuni file in una posizione di backup il primo giorno del mese. Il lavoro non è stato chiamato affatto - penso che sia launchd che controlla i lavori caricati contro il calendario che sta causando il problema. Non appena ho scaricato questo plist e ho spostato il file fuori dalla directory, UserEventAgent andava bene (dopo l'interruzione forzata). Il secondo che ho caricato il plist (launchctl load xxxx), UserEventAgent è andato fuori di testa.

StartCalendarInterval è una chiave valida per launchd come visto qui in Documenti di Apple .

Quindi, per chiunque abbia problemi, controlla le directory di LaunchAgent e cerca la chiave StartCalendarInterval (o qualsiasi altra chiave relativa al calendario). Non ho avuto alcun problema con gli elenchi degli intervalli basati sul tempo.

Nota: non corregge gli errori "Month 13 out of bounds", solo il comportamento pazzo di UserEventAgent.

Dopo aver segnalato questo ad Apple e ridimensionato la catena di escalation, mi è stato detto che questo dovrebbe essere corretto in macOS 10.13.3.

Apparentemente, questo è causato da un'applicazione che chiama la procedura NSDate deprecata 'descriptionWithCalendarFormat' .

Puoi leggere ulteriori informazioni al link .

In alcuni casi, la modifica o la rimozione di alcuni file plist impedirà ai programmi di chiamare la procedura deprecata, ma la vera correzione è un aggiornamento del sistema operativo.