¿Mes 13 está fuera de límites?

Puedo verificar la legitimidad de este problema. Yo tenía el mismo problema de ayer, y después de un reinicio, el equipo se vuelve casi inútil debido a este error. Por alguna razón, el equipo no se puede tratar con este mes y tira errores donde hay bases de datos o plists.

Para solucionar este problema:

1. Abrir el Monitor de Actividad y la fuerza de cierre de dos procesos: lsd, UserEventAgent

2. Abra Preferencias del Sistema y vaya a "Fecha Y Hora"

3. Desmarca la casilla "Ajustar la fecha y la hora automáticamente"

4. En el calendario, seleccione una fecha anterior a la fecha de diciembre de 2017, y pulse Guardar

5. Si UserEventAgent o lsd siguen causando problemas, entonces la fuerza que salir de nuevo después de la configuración de la fecha.

Otras personas aquí tienen este problema

Por qué?

A mí me parece, UserEventAgent estaba tratando de utilizar dos archivos plist:

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

y

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

Cuando se trató de utilizar los plists, se obtuvo un error:

Month 13 is out of bounds

No estoy seguro de lo que realmente sucedió dentro de UserEventAgent, pero es obvio que cuando se obtiene el error, no puede lidiar con eso y causa alta de la CPU y uso de memoria RAM.

A menos que usted está viendo otros problemas o el proceso de lanzar esta entrada del registro es tuyo (en cual caso ver post de este foro de desarrolladores de Apple) ignorar esto. Es una advertencia que una inconsistencia de los datos produjo dentro de un proceso - probablemente un error menor subyacente en MacOS o un menor error con ese proceso. No hay nada malo con tu configuración o hardware de Mac sin embargo.

Yo tenía el mismo problema con una muy alta UserEventAgent de la CPU y uso de memoria a partir del primero de diciembre de 2017. Consola mostró el "mes fuera de los límites de error", como se describe anteriormente.

Traté de utilidad de disco "primera ayuda", reinicia en modo seguro (a borrar la caché del sistema), borrar la NVRAM y SMD, nada ayudó. Me di cuenta de que la CPU y uso de memoria no pico en modo seguro.

Como @tgray y u/kidtexas, en algún punto me di cuenta de que si he desactivado todos los de mi costumbre launchd plists que el problema no se produce.

Yo, finalmente, escribió el pequeño script de abajo para que me ayude a depurar que plist que estaba causando el problema. Terminó siendo un plist que se ejecuta en el primer día de cada mes:

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

Muchos de mis plists el uso de la StartCalendarInterval clave, y usando el script de abajo te podría mostrar que ellos no parecen causar un rápido aumento de la memoria RAM y la memoria, por lo que no es del todo claro para mí por qué uno específico plist causa el problema. Independientemente, esta es la forma en que me ordenan.

I fuertemente recomendar a los lectores a mirar a través de la secuencia de comandos para tratar de entender lo que hace en lugar de simplemente copiar y pegar. Específicamente, como está escrito esto sólo funcionará para plists en ~/Library/LaunchAgents (no /Library/LaunchDaemons y otros), y que intencionalmente pruebas sólo plists cuyo nombre y <key>Label</key> siga el patrón específico: com.USERNAME.my_plist_name[.plist]. Antes de ejecutarlo, he utilizado un one-liner a bootout todos los de mi plists: for plist in com."$(whoami)".*.plist; do launchctl bootout gui/"${MYUID}"/"${plist%.plist}" || true; done, y luego verificar que ya no apareció bajo launchctl list de resultados.

#! /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

Como los demás, estaba teniendo un uso elevado de la CPU y el enorme consumo de RAM de UserEventAgent (ver mi comentario anterior). El cambio de la fecha para noviembre y forzar la salida de UserEventAgent arreglado las cosas. Todo esto comenzó el sábado después de reiniciar.

Revisión

Me di cuenta de esto por mí. Esperemos que para los demás con los problemas, que esto funcionará para usted.

El tema fue un LaunchAgent plist que tengo en ~/Library/LaunchAgents. Es un simple archivo plist que llama StartCalendarInterval, que es una clave válida para launchd plists. El LaunchAgent trabajo llama a un script de shell que copia algunos archivos a una ubicación de copia de seguridad en el primer día del mes. El trabajo no es ser llamado a todos - creo que es launchd comprobación de la carga de trabajos contra el Calendario que está causando el problema. Tan pronto como he descargado este plist y mueve el archivo fuera del directorio, UserEventAgent estaba bien (después de un forzar cierre). El segundo me ha cargado el plist (launchctl load xxxx), UserEventAgent se volvió loco.

StartCalendarInterval es una clave válida para launchd como se ve aquí en Apple docs.

Así que para cualquier persona que tenga problemas, compruebe su LaunchAgent directorios y busca el StartCalendarInterval clave (o cualquier otro calendario clave relacionadas). No tuve problemas con el tiempo de intervalo basado en plists.

Nota: Esto no soluciona el " Mes 13 fuera de los límites de los errores, sólo el loco UserEventAgent comportamiento.