Permissions problem in displaypolicyd

So has anyone actually managed to pinpoint the cause of this yet?

Well, the last couple of times I removed Dropbox, my problem was resolved. But, with this latest time I removed it, the problem is still happening. :-/

I haven't encountered any problem since booting my Mac at about 2 PM today. I repaired permissions which corrected the "displaypolicyd"-problem.

I have used my Mac for Lightroom work and browsing. No problem.

Run a check again, see if it has returned.

I don't have any problems with what I was having a problem with since I did the repair, but the errors still keep coming back.

The permissions verification results is not related to the OP's display sleep problem. It can be ignored. It is not a problem to be fixed by users. The permissions on the folder is expected. The folder is supposed to owned by user/group _displaypolicyd (244). Changing the permissions can cause problems by not allowing the displaypolicyd process from accessing the folder. The permission verification results is due to the Mac OS X OS package initially creating the folder with different permissions. I've included technical information below from my mac.

The system process that needs access to the folder:

USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND

_displaypolicyd 58 0.0 0.0 2560836 2888 ?? Ss 1:14AM 0:00.41 /usr/libexec/displaypolicyd -E 1 -k 1

The runtime files that the process creates and needs to access:

drwxr-xr-x 4 _displaypolicyd _displaypolicyd 136 Dec 28 13:21 /private/var/db/displaypolicyd

-rw-r--r-- 1 _displaypolicyd _displaypolicyd 4 Dec 28 01:14 /private/var/db/displaypolicyd/.pid

-rwx------ 1 _displaypolicyd _displaypolicyd 4276 Dec 28 13:21 /private/var/db/displaypolicyd/displaypolicyd.cache

The file information from the installer package receipt that is used to verify and repair permissions:

volume: /

path: /private/var/db/displaypolicyd

pkgid: com.apple.pkg.BaseSystemBinaries

pkg-version: 10.10.0.1.1.1412852630

install-time: 1413835468

uid: 0

gid: 0

mode: 755

pkgid: com.apple.pkg.BaseSystemResources

pkg-version: 10.10.0.1.1.1412852630

install-time: 1413835469

uid: 0

gid: 0

mode: 755

Let me tell you what I did, it may not work for you but for now I haven't had the problem with my display.

I did a fresh install of OS X Yosemite (since buying the macbook with Lion back in June, 2012, I just upgraded to the newest release over time).

After Yosemite finished installing I did a Permission Check, the problem was still there, repaired the permission and left the macbook until morning and experienced the problem with the display not turning on.

I think the mistake is when I did the Repair permissions, I haven't done it since installing the fresh copy of Yosemite and no more problem.

I've read that some of you had Dropbox and got the problem with the display. I don't use that service, never had it installed on my macbook, don't know if it's related to Dropbox.

I suffer from this issue as well. I recognize al lot from all the replies posted in this topic. Clean install, preparing permission after every reboot, nothing helps. It seems to be the root of other problems as well, like strange Safari and Finder crashes. I only do not blame Dropbox, I doubt it is Dropbox, it seems to be OS-X related.

I am running a Mac Pro from 2009 with OS-X 10.10.1 as a standard user. I did not suffer from it when I was running OS-X 10.10. It is not really clear to me how to fix this issue.

This sounds reasonable. But why keeps Finder + Safari crashing again and again?

I'm having the same issue for the past month or so.

First Time

1. Everything working fine (though in Fusion I was getting chronic blinking that would lose focus on the VM - upgrade to 7 fixed)
2. Walk away and come back - screen black
3. First time, reset PRAM worked, and screen back back on
4. Subsequent two times - NOTHING seems to make any difference (resetting PRAM and SMC don't fix anything)

Last week, I had the laptop connected to an external display because primary was black, and all of a sudden, the display just came back on (no rhyme or reason). It has worked perfectly for about 2 weeks.

This morning, I came into the office, hooked up an external monitor, everything working normally with extended display, <BLINK> laptop screen went black again. I did find a few errors in system.log regarding ambient light sensor, so I turned that off. I have also disabled any power management so the laptop no longer goes to sleep (it dims a little on battery - that is the only checkbox I have selected). I have also turned off automatic switching of graphics.

Every reboot breaks the permissions for this directory (owner and group set back to 244), so it looks like this directory must be created on startup of this displaypolicyd thing. I tried adding the "fixesPermissions.sh" script to my profile - no dice (but if the dir doesn't exist when it runs - that would make sense).

Permissions after reboot:

drwxr-xr-x 2 _displaypolicyd _displaypolicyd 68 Sep 25 22:22 displaypolicyd

I just found the displaypolicyd.log and .stdout.log files and I see this for every reboot:

u>3210670761 /usr/libexec/displaypolicyd: Started at Mon Jan 5 11:59:46 2015

u>3252012995 ERROR: AGDC suppport not present in system

u>3252013024 ERROR: Policy engine instance init failed

I also used:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.displaypolicyd.plist

sudo launchctl load /System/Library/LaunchDaemons/com.apple.displaypolicyd.plist

so I could watch the log and see what happens. On load, I get the above errors, and it doesn't seem anyone knows what this means. I saw one person speculate that the "battery was failing or there was a problem with RAM, PRAM, or the SMC" <not super helpful>.

Is AGDC something newer than my MBP? If that's the case - then I'm way down the wrong road because the problem is intermittent, and nothing I do seems to consistently fix it (like reset PRAM worked the first time - then not again, and resetting SMC did nothing. Then after I have resolved to just live with it for now and use an external monitor, the screen comes back on.. now its just gone back off. WTH, Apple??).

Hi everyone,

I'm having this super-annoying Yosemite-can't-see-my-display-even-though-it's-RIGHT-THERE issue as well. I've trawled all the forums (as I'm sure you all have) and none of the solutions worked for me, so I'm going to try installing Mavericks on a partition and see what happens. I'll post an update here.

My computer:

MacBook Pro 2012

OS X Yosemite 10.10.1

Can't detect a BenQ monitor

Mini DisplayPort to HDMI cable.

Carric,

The ownership for /var/db/displaypolicyd/ is supposed to be 244(_displaypolicyd). The "fixesPermissions.sh" script will actually cause failures with the display policy daemon. It will prevent the process from accessing its cache data. You will get the error: "NOTICE: doing display state recovery". You won't see it since the process is active on only a few specific mac models. It is active on my Mac Pro (Late 2013). It runs at boot and exits on my MacBook Air (13-inch, Mid 2012). On other systems, it will run at boot and exit with the error you posted regarding AGDC not supported. AGDC is the acronym for Apple Graphics Device Control. It is not supported on all mac models.

i have exactly the same problem since upgrading from 10.8 to 10.9.

i even bought a new imac 27" late 2013 and installed 10.10.1 fresh without migrating any old data from previous systems.

but my imac is not able to detect the second NEC display by default, as it was with 10.8. there, i booted, and the mac detected the second display.

i have done several PRAM resets and SMC resets and everything else, and it still persists.

additionally when i change the desktop image in settings (finder), it is not saved! when i reboot, i get the original yosemite desktop "hill" image on the second screen (and sometimes randomly on the imac, too)

i use a high-grade displayport to minidisplayport cable

thanks for any help

Have similar issue on my Mac.

But find better and easy solution for this issue rather than batch file from second post.

Open Terminal app.

And type this:

sudo dseditgroup -o edit -a root -t user _displaypolicyd

This will add root user to the _displaypolicyd group that the owner of the /private/var/db/displaypolicyd dir.

@ssh4net:

what is the result of your method please?

i did it, and no change.

Just adding root user to _displaypolicyd group.

/private/var/db/displaypolicyd dir always set owner _displaypolicyd:_displaypolicyd with permission write only for owner user or owner groups.

So in my situation no "blackscreen" with root in _displaypolicyd group. And i don't need repare permission to root:wheel (0:0) via console of via Disk Utility every time.

Can you check in console did _displaypolicyd exist in output from this command?

sudo groups