calendaricloudmacos
I'm using El Capitan, and I went to my Mac to check my calendar (which is sync'ed to iCloud). I needed to check the details of an appointment I had 3 years ago. I went back, opened that month, and I saw all my entries. And then after a second, they vanished.
Why did this happen, and how can I stop this from happening?
And, can I use Time Machine to retrieve my old Calendar entries?
Complementing other answers …
Mac OS X: How to start up in single-user or verbose mode
– if you start in verbose mode, then restart or shut down will be similarly verbose.
Hint: if things in verbose mode seem to not progress beyond a certain point, allow maybe five minutes before either:
If a forced restart does not succeed, that could be another clue to the cause of the problem(s).
A related question, albeit not problem-oriented: Can anyone interpret verbose shutdown messages?
The problem-oriented case here should be easier to resolve for lupincho. Fewer tea leaves.
A preference can be stored in NVRAM. Enter the following command in Terminal, and be prepared to enter your admin password:
sudo nvram boot-args="-v"
The next start of the system will be verbose.
Before each restart or shutdown, in Terminal:
sudo sysdiagnose
It's time consuming, but you need not investigate the results of all runs. Pay attention only if a problems arises.
For a case such as lupincho's:
sysdiagnose may reveal a problem before a restart or shut downMore specifically: if a run of sysdiagnose fails to progress beyond a certain point, knowing that point can help to gain a sense of the underlying problem.
During the run you can use the following key combination, repeatedly, to see whether things are progressing:
For the allmemory part of the sysdiagnose routine, Apple's two minute estimate may be wildly inaccurate. Be patient.
If you suspect that sysdiagnose fails to progress beyond a certain point, then key:
If repeated use of Control-C fails to abort sysdiagnose, then (in my experience with Mountain Lion) it's almost certain that an attempt to restart or shut down the operating system will fail.
In Finder, go to:
/private/var/log/shutdown_monitor.log
This file is typically empty, but may contain items of interest following a problematic shutdown. (I have little experience in this area.)
It's not unusual to have stray processes at shutdown. A stray can be problematic only if it is not killed.
If you suspect that WindowServer is not killed, and that this particular stray is contributory to shutdown failure: ask yourself whether any third party software makes nonstandard use of the WindowServer process.
Quick Look of a GrabFS view of WindowServer on Mountain Lion, with two displays:
If Lion is similar, then my gut feeling is that the cause of shutdown failures lies beyond WindowServer.
Whilst the machine is running normally, what response to the following command?
sudo launchctl list | grep --invert-match com.apple
Wonder whether any non-Apple software is contributory to the problem. Anti-virus, anti-malware software?
Aim for:
/private/var/log/com.apple.launchd/launchd-shutdown.system.log
It seems the default is one log per shut down, with a maximum of two so there's also:
/private/var/log/com.apple.launchd/launchd-shutdown.system.log.1
Following any forced restart or forced shut down, you might choose to set aside a copy of the most recent of the two. If force is required on any more than one occasion, you can compare files to see whether a pattern emerges.
Don't rule out the possibility of an issue with third party software, even release quality. Little Snitch may be well written and widely respected but:
I tested Build 12A269 of OS X 10.8 for around two weeks before it was released, with particular attention to shut down behaviours in difficult situations. Whilst I have not watched any videos from WWDC 2012, I do have a sense that Apple has worked very hard to prevent the need for force in all but the most difficult situations.
At least on Mountain Lion, I see the load of Little Snitch 3.0 Preview 2 (3857) very early – before shutdown logging begins. If things relating to this KEXT are similarly late around shutdown time, then maybe an issue will be not evident in the usual log files on disk.
If ever you discover the cause of the problem – with either Lion or Mountain Lion – I'll be pleased to know.
In the meantime, with big thanks for the bounty, a closing thought:
kextstat -l | grep --invert-match com.apple
Your Calendar must be set to automatically accept invitations from email.
CHECK FOR THIS SETTING:
Automatically retrieve CalDAV invitations from Mail
Select this checkbox to have Calendar get event invitations from Mail.
Go to Preferences in your Calendar and turn it off. (for now)
Next, set junk filtering in your Gmail.
Also block this specific user.
Just to make sure, change your Gmail password.
Clean all Internet saved browsing (the history) including cookies.
Then run a virus scanner to finalize.
Once you are sure you got your Gmail account under control with decent junk filtering, you can turn the auto Calendar invites on, if you wish to use it.
If there is a leftover from previous owner, check the Delegation set up in Calendar, by clicking on the EDIT. There should be no names in there.
Best Answer
The problem is resolved.
On my iPhone, all the old entries were still there. But restarting the Mac and going to Calendar again, the same thing happened: The old items displayed and disappeared. However, disabling the iCloud calendar and then re-enabling sync for my iCloud calendars appears to have caused the problem to resolve.