Periodic errors authenticating caldav/carddav

Question

Level 1

0 points

Periodic errors authenticating caldav/carddav

I'm having users from iCal and via their iPhones get periodic errors while trying to connect to our MacOS X Lion server. The caldav logs show an odd error:

2012-04-11 14:24:53-0700 [-] [caldav-6] [PooledMemCacheProtocol,client] [calendarserver.platform.darwin.od.opendirectory#error] Error Domain=com.apple.OpenDirectory Code=5205 "Authentication server encountered a communication error while attempting the requested operation." UserInfo=0x7fc5e2f1db00 {NSLocalizedDescription=Authentication server encountered a communication error while attempting the requested operation., NSLocalizedFailureReason=Authentication server encountered a communication error while attempting the requested operation.}

2012-04-11 14:24:53-0700 [-] [caldav-6] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryRecord#error] OpenDirectory (node=xxx.seatme.com) error while performing digest authentication for user jordan: Error Domain=com.apple.OpenDirectory Code=5205 "Authentication server encountered a communication error while attempting the requested operation." UserInfo=0x7fc5e2f1db00 {NSLocalizedDescription=Authentication server encountered a communication error while attempting the requested operation., NSLocalizedFailureReason=Authentication server encountered a communication error while attempting the requested operation.}

So it seems that ocacssionally, the connection to OpenDirectory simply fails. Has anyone else run into this problem? We have about 50 devices hitting this server and when it happens, iCal prompts the user saying their password is invalid and asks them to enter their password again which is subpar to say the least.

Mac mini Server (Mid 2011), Mac OS X (10.7.3)

Posted on Apr 11, 2012 2:39 PM

Reply

Answer 1

Aloisius Author

Level 1

0 points

Apr 11, 2012 3:32 PM in response to Aloisius

It seems the opendirectory server is somehow unable to connect to the LDAP server?

2012-04-11 14:57:06.409 PDT - 34416.747, Node: /LDAPv3/127.0.0.1, Module: AppleODClient - unable to send command to Password Server - sendmsg() on socket fd 9 failed: Broken pipe (5205)

2012-04-11 14:57:06.661 PDT - 34416.761 - Client: Python, UID: 93, EUID: 93, GID: 93, EGID: 93

2012-04-11 14:57:06.661 PDT - 34416.761, Node: /LDAPv3/127.0.0.1, Module: AppleODClient - unable to send command to Password Server - sendmsg() on socket fd 9 failed: Broken pipe (5205)

2012-04-11 14:57:06.663 PDT - could not get peer sockaddr info for 9

2012-04-11 14:57:06.663 PDT - 34416.763 - Client: Python, UID: 93, EUID: 93, GID: 93, EGID: 93

2012-04-11 14:57:06.663 PDT - 34416.763, Node: /LDAPv3/127.0.0.1, Module: AppleODClient - unable to send command to Password Server - sendmsg() on socket fd 9 failed: Broken pipe (5205)

2012-04-11 14:57:06.664 PDT - could not get peer sockaddr info for 9

2012-04-11 14:57:06.664 PDT - 34416.765 - Client: Python, UID: 93, EUID: 93, GID: 93, EGID: 93

2012-04-11 14:57:06.664 PDT - 34416.765, Node: /LDAPv3/127.0.0.1, Module: AppleODClient - unable to send command to Password Server - sendmsg() on socket fd 9 failed: Broken pipe (5205)

Sadly I don't see anything in the slapd logs outside warnings that certain things are not indexed.

Reply

Answer 2

matwyn

Level 1

10 points

Apr 12, 2012 2:22 AM in response to Aloisius

No answers for you but at least you're not alone - we've been getting the same thing but only for about the last week (before any SU were applied). The only thing we've done so far is to restart the iCal service, which seems to kick it back in, but only temporarily.

The odd thing is, is doesn't happen all the time and quite often just leaving the connection to wait for a few minutes it will also re-connect succesfully. It only constantly fails if we keep re-entering the name and password over and over again.

Reply

Answer 3

Apr 26, 2012 6:29 AM in response to Aloisius

I am seeing this same issue on some Lion Servers that I've set up. When it happens users of caldav, carddav and jabber start getting authentication errors and the "unable to send command to Password Server" starts flooding my logs.

Does anybody have anything else to add to this right now, anybody find a workaround? I'm continuing to try to debug this as I know it's only a matter of time before it happens again.

Reply

Answer 4

May 23, 2012 5:33 AM in response to Aloisius

I have been having the same problem.

The only fix is either restarting the server or restarting the different services. This also happens to my mail accounts.

Are there any new insights since the original post in April?

Reply

Answer 5

May 23, 2012 6:59 AM in response to Aloisius

I've got the same deal going on. Had a few weeks with no problem after 10.7.4, kicked back in after adding a Group in Server.app (which seems to have similar intermittent auth problems). At least daily again. Just 4 users.

Reply

Answer 6

May 30, 2012 12:32 PM in response to tommyrock

I'm having the same issue. The last time was last night and it seems servermgrd was the first service to fail. Here are what I am seeing in my log files:

2012-05-29 20:12:37.155 MDT - 61866.2625706 - Client: servermgrd, UID: 0, EUID: 0, GID: 0, EGID: 0
2012-05-29 20:12:37.155 MDT - 61866.2625706, Node: /LDAPv3/127.0.0.1, Module: AppleODClient - unable to send command to Password Server - sendmsg() on socket fd 22 failed: Broken pipe (5205)

I have created a bug in radar with the following id#: 11558787

If you suffer from this issue go file a bug at https://bugreport.apple.com. The more reports, the more likely Apple is to look at, and address the issue.

Reply

Answer 7

May 30, 2012 1:30 PM in response to Mr Beardsley

First, I too am still dealing with this bug. It seems to crop up about every 2-3 weeks. I was getting extremely ****** by this bug as it was annoying all of our users when it would occur. Now I've come to the conclusion that while annoying, it's not the end of the world and a "fix" can possibly be scripted to keep things running smoothly all the time.

The quick fix is to kill the PasswordService and then kill opendirectoryd.

Doing this will cause them to respawn and everything should return to normal.

I am toying around with the idea of scripting this so I don't even have to worry about it. Something along the lines of using the WatchPaths key in launchd to watch /private/var/log/opendirectoryd.log for changes and then kill Password Server and Open Directory.

Reply

Answer 8

Jun 11, 2012 11:30 AM in response to Aloisius

For anyone interested, I finally broke down and wrote a script that takes care of this problem. You use the WatchPaths key in launchd to watch /private/var/log/opendirectoryd.log. When the opendirectoryd.log is modified, the script executes and checks for this error. If it sees it's occuring, it kills passwordservice and opendirectoryd and exits. Problem "solved".

#!/bin/bash if tail -n20 /private/var/log/opendirectoryd.log | grep -q "Broken pipe"           then              killall PasswordService;              sleep 5;              killall opendirectoryd;              sleep 5;              exit; fi

Reply

Answer 9

Jul 3, 2012 7:50 AM in response to Aloisius

Aloisius: did you ever solve this problem?

Reply

Answer 10

Aloisius Author

Level 1

0 points

Jul 5, 2012 11:18 AM in response to Martin Baechtold

We work-around it using what Jonathan Miller posted. Specifically:

/Library/LaunchDaemons/com.seatme.checkpwservice.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<dict>

<key>Label</key>

<string>com.seatme.CheckPwService</string>

<key>ProgramArguments</key>

<array>

<string>/usr/local/bin/checkpwservice</string>

</array>

<key>WatchPaths</key>

<array>

<string>/private/var/log/opendirectoryd.log</string>

</array>

<key>StandardOutPath</key>

<key>ThrottleInterval</key>

</dict>

</plist>

/usr/local/bin/checkpwservice (from Jonathan):

if tail -n20 /private/var/log/opendirectoryd.log | grep -q "Broken pipe"

then

killall PasswordService;

sleep 5;

killall opendirectoryd;

sleep 5;

exit;

fi

Then load it:

chmod 755 /usr/local/bin/checkpwservice

launchctl load -w /Library/LaunchDaemons/com.seatme.checkpwservice.plist

Reply

Answer 11

Jul 5, 2012 11:20 AM in response to Aloisius

Awesome, glad this it's saving somebody else from this headache!

Reply

Answer 12

Uzilurcs

Level 1

0 points

Jul 9, 2012 7:04 AM in response to Aloisius

Hi,

the Script is not required any more.

type in console:

echo "limit maxfiles 10240 120000" > /etc/launchd.conf

then Reboot.

The "Broken Pipe" Error is gone away.

bye

Reply

Answer 13

Jul 9, 2012 7:12 AM in response to Uzilurcs

Are you fully aware of what this command will even do? (I'm not, so I'm not doing it!)

Editing launchd.conf is like poking your server's brain with a stick. You can end up causing more problems than you tried to solve. I'm sticking with shell script approach.

Reply