Q: strange calendar errors, python process taking CPU
I have Server 5 freshly migrated on top of Yosemite.
I've migrated from Server 3 to 4 and now to 5. My websites all made it. My email service is fine.
I've never used the calendar service, and it used to spam my System log with goofy errors in Server 4. I thought that would be fine in Server 5, seeing as 5 fixed issues for many in the threads here.
Not for me. So I tried to enable it. I get this error in the Calendar error log:
2016-02-14 22:45:25-0600 [-] (UNIX Port '/var/run/caldavd/caldavd.sock' Closed)
2016-02-14 22:46:20-0600 [-] Log opened.
2016-02-14 22:46:20-0600 [-] ControlSocket starting on '/var/run/caldavd/caldavd.sock'
2016-02-14 22:46:22-0600 [-] [txdav.base.datastore.subpostgres#error] Unable to connect to database for schema creation: [Errno 32] Broken pipe
2016-02-14 22:46:23-0600 [-] [txdav.base.datastore.subpostgres#critical] Can't start or connect to postgres: md5 password authentication failed
2016-02-14 22:46:23-0600 [-] (UNIX Port '/var/run/caldavd/caldavd.sock' Closed)
Is there a way that I can just delete Calendar service and let Server app make it all fresh? I won't lose any data because I've never used it.
Meanwhile, my otherwise happy server is stuck using 9% CPU because there's some Python and postgres processes that keep taking up 100% CPU when I watch in top. How can I get Calendar back to factory?
Posted on Feb 14, 2016 9:57 PM
Just to help anyone else looking for this later one.
There are several threads laying around where _teamserver and python go off the charts. Literally, one of the cores on my poor mini server (fortunately, I have a quad core) has been pegging out at 80-100% for several days over this mess -- sys cpu was around 4% and user CPU hovering are 15% the entire time.
The root problem comes from what I posted above -- somewhere in the configuration files that had been either half-migrated, not migrated, or corrupted along the path, some plist was trying to use the wrong hashlib.py definition and it was causing the calendar server to be unable to keep the postgres process connected to the caldav socket. This was generating a constant reconnection. That reconnection was dumping logs into the postgres journal. These services have a postgres archive journal activated. When working, it's a great thing because it's a rolling log of database history. Unfortunately, when reconnection cause several kb of logs to be generated every five seconds, you can get 100s of gb of logs piling up quickly.
To top it all off, it appeared to me that the corrupt/incomplete migration never actually migrated the database itself, thereby further compounding the mess -- so there were (null) IDs in the database. I'm not so dedicated to it that I could get that fixed.
I was not able to chase down the precise issue. I did fix it, however. I had no old data to migrate. So I went with a chance and set out to reset Just the Calendar services of the server app.
I've seen threads of people asking, and I can now confirm that this worked to reset only the Calendar service:
- Toss the Server.app to the trash. Wait for the script to trigger the pop up confirmation. Click OK.
- Empty the contents of /Library/Server/Calendar and Contacts.
- Move Server.app back to Applications folder.
- Start Server. Wait for the migration scripts to run.
- Start services.
Calendar, wiki, contacts... all of them started nicely. web service works perfectly. More importantly, my load all dropped to normal again. sys CPU (before I turned web services back on was 0.5% and user was 2%. that's what I expect and have come to see as normal (as long as the wordpress sites aren't getting hammered).
Thanks for attempting to help me, Drew!
Posted on Feb 17, 2016 8:16 PM