Als Mail actief is, gaat de iMac niet in sluimerstand. Bij "verhindert sluimerstand" onder "Energie" in Activiteitenoverzicht staat ook "Ja" bij Mail. Een herstart brengt geen soelaas.

Als ik in Terminal de command line pmset -g assertions intik, krijg ik het volgende overzicht:
Assertion status system-wide:
BackgroundTask     1
ApplePushServiceTask   0
UserIsActive     1
PreventUserIdleDisplaySleep 0
PreventSystemSleep    0
ExternalMedia     1
PreventUserIdleSystemSleep  0
NetworkClientActive   0
Listed by owning process:
pid 278(UserEventAgent): [0x00003945000b88d1] 00:00:25 BackgroundTask named: "com.apple.mail.AttachmentMIMESnip"
 Created for PID: 2013.
pid 68(powerd): [0x0000002400088000] 21:57:40 ExternalMedia named: "com.apple.powermanagement.externalmediamounted"
pid 119(hidd): [0x0000389b0009888d] 00:03:15 UserIsActive named: "com.apple.iohideventsystem.queue.tickle"
 Timeout will fire in 175 secs Action=TimeoutActionRelease
Kernel Assertions: 0x104=USB,MAGICWAKE
id=501 level=255 0x4=USB mod=1/01/70 01:00 description=com.apple.usb.externaldevice.fa130000 owner=Keyboard Hub
id=502 level=255 0x4=USB mod=1/01/70 01:00 description=com.apple.usb.externaldevice.fa120000 owner=P'9221 Mobile Drive
id=503 level=255 0x4=USB mod=1/01/70 01:00 description=com.apple.usb.externaldevice.fd140000 owner=Apple Optical USB Mouse
id=504 level=255 0x4=USB mod=1/01/70 01:00 description=com.apple.usb.externaldevice.fd130000 owner=HL-2240 series
id=505 level=255 0x100=MAGICWAKE mod=2/11/16 11:06 description=en1 owner=en1
Idle sleep preventers: IODisplayWrangler

De background task "com.apple.mail.AttachmentMIMESnip" lijkt de boosdoener. Veel informatie kan ik daarover niet vinden.

Onder El Capitan en de oudere besturingssystemen stelde dit probleem zich niet.

Als ik een nieuwe gebruiker aanmaak en Mail met dezelfde instellingen configureer, gaat de Mac wel in sluimerstand.

Een clean install lost het probleempje waarschijnlijk op, maar dat vind ik in dit geval wel overkill. Iemand met een suggestie voor een andere oplossing?

(Bewerkt door Pertinax om 21:38, 28-11-2016)

(Bewerkt door Pertinax om 21:42, 28-11-2016)

Gek genoeg is voor sommigen het resetten van de printqueue en/ of het verwijderen van je printers uit de lijst een remedie tegen die insomnia.

Research link chain:

pid 96(hidd): [0x00000074000901cc] 00:01:01 UserIsActive named: "com.apple.iohideventsystem.queue.tickle"
isn't the issue, that just saying is not sleeping because the user is currently active.
What preventing sleep is:
Idle sleep preventers: IODisplayWrangler
which shouldn't be there. I found a Apple support forum with a few possible fixes.

Bron:
https://www.reddit.com/r/applehelp/comments/43ks7u/macbook_wont_go_to_sleep_hidd_preventing_sleep/

Sublink:
https://discussions.apple.com/thread/7256162?start=0&tstart=0

Sublink:
https://support.apple.com/kb/PH18614?viewlocale=en_US&locale=nl_NL

Hopelijk helpt dit.

(Bewerkt door HEXDIY om 1:11, 3-11-2016)

pid 278(UserEventAgent): [0x00003945000b88d1] 00:00:25 BackgroundTask named: "com.apple.mail.AttachmentMIMESnip"
Created for PID: 2013.

Open Activiteitenweergave, zoek alles wat te maken heeft met PID 2013 en force quit dat met de rode stopknop links bovenaan.

Gaat je Macje dan slapen?

(Bewerkt door HEXDIY om 1:55, 3-11-2016)

De combo-update heb ik gedraaid.

PID 2013 hoorde bij het programma Mail (de PID's worden als ik het goed begrepen heb door het OS toegewezen en zijn variabel). Ik heb Mail geforceerd uitgeschakeld in Activiteitenoverzicht. De background task com.apple.mail.AttachmentMIMESnip verschijnt dan niet in Terminal en de Mac kan weer sluimeren, maar zodra Mail geactiveerd wordt, komt de taak terug en raakt de Mac niet opnieuw in sluimerstand.

IOdisplayWrangler heeft kennelijk geen invloed. Ik zie het met de command line pmset -g assertions iedere keer in Terminal opduiken, ook als Mail niet actief is en de Mac wel probleemloos in sluimerstand gaat.

Ik had ook gelezen dat het verwijderen van printers of het resetten van de printqueue sluimerprobleempjes kan oplossen. Ik had dat al gedaan, maar zonder resultaat.

Bedankt voor het meedenken toch! Het is geen halszaak...

Stom dat het zolang heeft geduurd, want Safe Boot is 1 van de krachtigste gereedschappen om stomme problemen op te lossen.

Afgelopen weken al een paar keer tegengekomen hier.

pmac

Of dat die systeemcaches abnormaal snel vollopen of zoiets, wat op hetzelfde neerkomt.

Veilige Modus aka Safe Boot schoont namelijk ook een aantal systeemcaches op...

@ Pertinax

Nou nog 'opgelost' in de naam van het draadje zetten en het is weer netjes zoals het hoort

pmac