jmansfield04

Q: Mavericks Server Delegates Drop off

I've been having an ongoing issue with Calendar delegates using the calendar service. Periodically delegates will disappear from iCal and also disappear from the list of potential delegates under the account settings. OS X server 10.9.1. Server app is version 3.0.2. I have around 50 users, each user has delegated access to their calendar to around 10-20 other users.  Workstation accounts are configured as OS X Server accounts in the Internet Accounts System Preference. Workstations are using the server for DNS. All the accounts are Network User accounts (OD). When the error happens I will generally get log errors like these. Any ideas?

 

2014-02-12 10:07:29-0500 [-] [caldav-3]  [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryRecord#error] OpenDirectory (node=server.ethos-marketing.com) error while performing digest authentication for user username: <OD Error Record not found 0>

2014-02-12 10:08:06-0500 [-] [caldav-3]  [-] [twext.web2.channel.http#error] Connection aborted - took too long to close: IPv4Address(TCP, '72.224.88.254', 60020)

2014-02-12 11:16:07-0500 [-] [caldav-0]  [-] [twext.web2.channel.http#error] Connection aborted - took too long to close: IPv4Address(TCP, '192.168.1.135', 60626)

2014-02-12 11:16:07-0500 [-] [caldav-2]  [-] [twext.web2.channel.http#error] Connection aborted - took too long to close: IPv4Address(TCP, '192.168.1.115', 61003)

2014-02-12 11:58:36-0500 [-] [caldav-0]  [-] [twistedcaldav.method.report_multiget_common#error] Missing resource during multiget: /calendars/__uids__/1DB3C766-13A8-49CD-82C7-77495CB1EB3E/inbox/6e54fde6d2e60246 e73fabb254d58ff6-c0423d4e.ics

2014-02-12 12:39:28-0500 [-] [caldav-6]  [-] [twext.web2.channel.http#error] Connection aborted - took too long to close: IPv4Address(TCP, '72.224.88.254', 61633)

2014-02-12 12:39:28-0500 [-] [caldav-4]  [-] [twext.web2.channel.http#error] Connection aborted - took too long to close: IPv4Address(TCP, '72.224.88.254', 61634)

2014-02-12 12:39:28-0500 [-] [caldav-3]  [-] [twext.web2.channel.http#error] Connection aborted - took too long to close: IPv4Address(TCP, '72.224.88.254', 61630)

2014-02-12 14:16:15-0500 [-] [caldav-7]  [-] [twext.web2.channel.http#error] Connection aborted - took too long to close: IPv4Address(TCP, '70.192.15.220', 12072)

MAC MINI SERVER (LATE 2012), OS X Mavericks (10.9.1), O X Server

Posted on Feb 12, 2014 12:07 PM

Close

Q: Mavericks Server Delegates Drop off

  • All replies
  • Helpful answers

Previous Page 2
  • by jmansfield04,

    jmansfield04 jmansfield04 Jun 13, 2014 3:12 PM in response to Tarny
    Level 1 (0 points)
    Jun 13, 2014 3:12 PM in response to Tarny

    I found that when the Time Machine backup ran my delegates would drop off daily, something about taking the database offline for the backup perhaps? With Time Machine off they would stick for about a week before a mass drop off. Gave up and now using Google Apps calendars with delegation. Works much better.

  • by ~morgen,

    ~morgen ~morgen Jun 13, 2014 3:13 PM in response to Tarny
    Level 1 (140 points)
    Jun 13, 2014 3:13 PM in response to Tarny

    Ok, as for these:

     

    • error while performing digest authentication

     

    There should be more to the above message, including the user name and underlying OD error.  Is the username displayed in that message the internal "com.apple.calendarserver" user, or an actual user's account name?

     

    • Connection aborted - took too long to close

     

    I believe this is seen when a client on a flaky network, say a mobile phone, doesn't fully close a connection.

     

    Neither of those should have anything to do with the delegates issue.

     

    Keep us posted with the result of your file timestamp change detection, that should be helpful in resolving this to see if it correlates to any other activity.

  • by jmansfield04,

    jmansfield04 jmansfield04 Jun 13, 2014 3:14 PM in response to ~morgen
    Level 1 (0 points)
    Jun 13, 2014 3:14 PM in response to ~morgen

    Forgot to mention it was Time Machine backups running on the server causing the drop offs, not the clients.

  • by Tarny,

    Tarny Tarny Jun 13, 2014 3:39 PM in response to ~morgen
    Level 1 (15 points)
    Jun 13, 2014 3:39 PM in response to ~morgen

    Yes, there were more to those two error messages. There was an OD error, but it was temporary and later attempts right after the error were successful. The Connection Aborted was from a mobile device. I'm not concerned about that.

     

    As for the suggestion that the Time Machine service as a possible cause. I doubt it. Apple made great strides in integrating Time Machine with Server and much more critical service databases are successfully backed up with the /Applications/Server.app/Contents/ServerRoot/usr/sbin/ServerBackup command. (Think Postgres) And, to top it off, that Sqlite3 database file hardly every changes (except when I have to fix it.) So the probability that a write to that database is occuring just as TM is accessing it is very low. in fact a quick ps aux | grep sql command will show that sqlite is not usually running (though Postgres is) and also checking with fs_usage shows that it is very rarely accessed (usually by a Python process).

  • by Tarny,

    Tarny Tarny Jun 17, 2014 7:54 AM in response to Tarny
    Level 1 (15 points)
    Jun 17, 2014 7:54 AM in response to Tarny

    Ok, after 3 days, it appears that the delegates getting dropped from the database problem is in remission. I can't say cured because I couldn' t recreate the problem at will and then try out fixes. The last changes that may have affected the solution were to the physical network. The server is (unfortunatly) at the end of a very long ethernet cable. We actually don't know how long as the the installation of the cables occured before the customer took possesion of the building. The wall outlet is a typical 2 RJ45 plate and both sockets are live and connect to the switches. A few weeks ago I had noticed what I thought might have been interference of one port with the other port during a series of large file transferrs. But, as with many things, getting the file transfers accomplished was a higher priority than investigating the potential problem with the ports. Remembering this notion, I deliberatly disconnected one of the ports from server (it was in use for redundant purposes only.) And also from the switch. If that was the fix, then so far so good.

     

    However, it really bugs me that a networking problem, could rise to the level of a service process and cause the database to be dropped. So, I'm still watching for changes to that database with an automated process and a log file.

     

    Attempting to recreate a poor network connection on a test server to try to get it to fail has been frustrating and futile so far.

  • by Mike Vos,

    Mike Vos Mike Vos Aug 5, 2014 3:02 AM in response to Tarny
    Level 1 (15 points)
    Aug 5, 2014 3:02 AM in response to Tarny

    Hi Tarny,

     

    Any news on the subject?

    I have several servers with the same issue.

    In my/our experience, the read/write delegates stay functional.

     

    Regards,

    Mike

  • by Swordfish,

    Swordfish Swordfish Nov 26, 2014 1:50 PM in response to Mike Vos
    Level 1 (20 points)
    Nov 26, 2014 1:50 PM in response to Mike Vos

    Hi

     

    I'm also looking for a solution to this same issue. Time machine is running on the server but so far the drops are too rare to be caused by TM.

    Any further info on the solution would be nice.

     

    Regards,

  • by Petr 24u,

    Petr 24u Petr 24u Dec 11, 2014 6:43 AM in response to Swordfish
    Level 1 (0 points)
    Dec 11, 2014 6:43 AM in response to Swordfish

    Hi,

     

    my company is suffering with the same issue as described above by Tarny (down to the lines in /var/log/caldavd/error.log). The biggest difference is probably that my issues started shortly after we have migrated the server to a new computer (new hw, no change in setup).  I have created a PTR record on the external IP my users are using to connect from the outside. I have even tried to switch off the time machine. The delegations keep dropping.

     

    I also suspect the poor network connection to be somehow the source of the issue. I am mostly getting complaints about this on Monday mornings. That means that my users have been connecting to the company over the weekend though dedicated external ip or through VPN. When they return monday morning, their delegations are gone.

     

    I have not noticed read only / read write access rights to have any effect on how long does it hold together. On the other hand, most delegations in our company are of the read - only sort.

     

    I have just finished playing with the Server 4 and Yosemite. I am considering the upgrade in hope that the issue will solve itself somehow .  Has anyone been already down this way?

  • by CharlesY,

    CharlesY CharlesY Mar 25, 2015 3:03 PM in response to jmansfield04
    Level 1 (9 points)
    Mar 25, 2015 3:03 PM in response to jmansfield04

    So I had this issue on a client's OSX Server. They had a poorly configured computer name.

     

    Hostname: machine.domain.com

    Computer name: machine.domain.com

     

    The computer name should have been simply (ie no domain part): machine

     

    It's easiest to set using Server.app in the Server -> Overview area.

     

    BTW this cleared up a plethora of weird behaviors.

  • by grayloon,

    grayloon grayloon Dec 28, 2015 6:19 AM in response to CharlesY
    Level 1 (0 points)
    Dec 28, 2015 6:19 AM in response to CharlesY

    I'm experiencing this same issue with multiple accounts. The hostname is the standard ical.domain.com format, and the computer name is iCal. I haven't touched the sqlite DB because I'm not comfortable doing that. Time Machine is not configured on this server - I use a separate backup app.

     

    Anyone have further suggestions?

     

    OS 10.9.5

    Server.app 3.2.2

Previous Page 2