hangs on "signpost_notificationd Skylight"

Have noticed in Activity Monitor the "signpost_notificartiond" Dameon is using about 940kb after a cold boot. Once it is "Forced Quit" and sit maybe 30 seconds, the same signpost... drops from 940kb to 808kb and immediately Console stops getting any error messages (thousands). Can only hope Apple gets it fixed soon.

Have updated to 10.13.5 and running fine for 8 hours now. Console error messages of "signpost_notificationd Skylight" have ceased.

Apple has just released a Security Update for HS. Have not yet installed but once done will report back. In the mean time try this at your own risk. I have and had no negative impacts thus far.

try this

With No Applications active>> Desktop>> GO>> Utilities and look for Activity Monitor. Open Activity Monitor. In top Right of Activity Monitor type signpost_notificationd. In main screen of Activity Monitor you should see signpost_notificationd. Click on that process until it is hi-lited. In Top Left of Activity Monitor look for First Icon that looks like a large X >> that should be Force Quit. Although you try to Force Quit it will not.

If you are successful, quit Activity Monitor and Open Console. Let it run 1 - 2 minutes. If all goes well all those Error messages related to Signpost_notificationd will have ceased ( only until the next reboot )

Good luck

I too am affected by endless errors in console absolutely killing my performance. Mac Mini late 2014 clean install. The only thing that works for now (until the next reboot) was going into Terminal and:

type:

sudokillall -9 signpost_notificationd

hit Return key

and then the user (admin) password for the Mac

hit Return key

Quit Terminal

10.13.5 seem to have addressed this "signpost_notificationd Skylight" issue, all's quiet on my console since recent update

Those "pain in my __ss" errors have stopped for me as well with force quiting "signpost_notification" process, I too submitted a Bug report to Apple https://developer.apple.com/bug-reporting/

issue now closed

With No Applications active>> Desktop>> GO>> Utilities and look for Activity Monitor. Open Activity Monitor. In top Right of Activity Monitor type signpost_notificationd. In main screen of Activity Monitor you should see signpost_notificationd. Click on that process until it is hi-lited. In Top Left of Activity Monitor look for First Icon that looks like a large X >> that should be Force Quit. Although you try to Force Quit it will not.

If you are successful, quit Activity Monitor and Open Console. Let it run 1 - 2 minutes. If all goes well all those Error messages related to Signpost_notificationd will have ceased ( only until the next reboot )

Good luck

Don't understand how this can't be affecting more people. I have a iMac Retina 5k (late 2015 model) and I clean installed 10.13.4 and have this problem after a fresh install (no restore from backup). I also have a 2014 Retina MacBook Pro with 10.13.4 and it doesn't have the problem.

Force killing the signpost_notificationd process is the only way I can actually use my machine, but its hardly an acceptable solution for a clean installed operating system...???

As mentioned, Apple has known about this since April 4, 2018. Even, like you, Erase and clean install 10.13.4 on both late 2012 iMac ( spinner drive ) and early 2016 12' Retina MacBook 512 GD SSD and still the signpost_notificationd issue unresolved. Even with the latest Security Update of yesterday. Uploaded Data Collection files to Apple for a week and never any feedback from them at all.

For me, no measurable negative performance hits except battery in 12" Retina MacBook discharges a bit faster. This I attribute to Console being flooded with error messages signpost_noticicationd. Once I Force Quit the process, battery seems ( no numerical figures to support ) seems to last longer.

Until they do something, no options but force quit.

Good work there.

Now, strongly suggest all those affected by these error message, degraded performances, contact Apple Support and submit more reports. From what they told me, boilerplate answers, they have not heard of this issue before now. Further, some of the Support Staff did not even know 10.13.4 was released and thought 10.13.3 was the latest Public Official Release. Draw your own conclusions.

Can confirm these persistent signpost_notoficationsd in console do not appear in 10.13.3 or 10.13.3 Supplemental. Have a CCC of both that I booted from and no the error do not appear.

Realize this is not a sexy problem with little to not degradation in system performance. Thus no real traction in web and cry for fix from Apple. Therefore, low priority to get fixed.

Though the 10.13.4 seven beta testing would have made this update rock solid - mistake on my part to believe.

Starting to look at possible downgrading to Sierra 10.12.6

Thanks for additional info. Wish Apple was as picky on coding OS as they are on Bug Reports.

That said, have read elsewhere, the signpost_notificationsd, is somehow related to the rewrite of Metal 2 to accommodate the eGPU added in 10.13.4. Maybe 10.13.5 or beyond will get things right.

I installed the Security Update for High Sierra 2018-001 on an afflicted iMac, and the problem persists, with Force Quitting the signpost_noficationd process as the only (temporary) abatement.

I really don't think Apple cares anymore.

I think it likely there are two concurrent reasons: 1) is that users with SSDs aren't AS affected by the issue thanks to the speed delta of SSD over HD, they just don't "feel", it and 2) I had been tracking a performance issue with hard drive based iMacs (all 21", 2011s and 2012s) running 10.13.3 since late 2017 that I –think– traces to a "bad" Security Update in early December. The signpost_notificationd issue DEFINITELY showed up in 10.13.4, and has made the "performance" issue worse for older hard-drive-based Macs. I am not personally on 10.13, mostly because it started out as a dumpster fire and I'm already on an unsupported 2009 13" MacBook Pro (with 2TB of SSD storage) happily with 10.12, and I had an across-the-board "don't upgrade to 10.13" order with my clients. So I simply wasn't bothering to track issues with 10.13 until two iMacs showed up, both with similar 10.13/12/02/2017 Security Update "histories" and an extreme slow-performance issue.

If you're handy with Terminal, you can do a "softwareupdate --history --all" (might need to sudo, or be an Admin, not sure) and get a list of all the updates that have been run on a machine; look for a SU_TITLE on or around 12/02/2017. I'm wondering if we might not find a commonality that the "seed" for this got planted some time back with a bad silent update that Apple pushed and then silently "updated" (which happens more than Apple admits). I was seeing a ton of sandboxd DENY and fsevents DENY errors in the /tmp/ directory that looked like the system was improperly not allowing a "silent" security update to complete, though I'm now wondering if some of them might not have something to do with iCloud Safari Continuity syncing. The "companion" updates run on the same date/time was Security Update 2017-001, and an XProtectPlistConfigData update and MRTConfigData update; those last two usually coincide with a Gatekeeper Configuration Data, but this time did not. 5 days later on 12/07/2018, all three got updates. Looked like a silent "patch" to me. Which might have failed. And any machines that had "missed" the 12/02 updates might not have had a "bad seed" get planted, or a "ticking timebomb", whichever simile you prefer, and are running fine. But I don't know for certain; I only have seen these 2 units and I'm still warning people off of updating to 10.13 entirely.

Basically, 10.13 is stuck on stupid and Apple a) doesn't pay me to do their QA and b) doesn't even respect my effort enough to provide adequate... no ANY! resources to help them diagnose their bugs. Ergo, I mostly have given up.

ScotterComputer,

You have done much to track-down this stupid signpost_notificationd error messages. Much of what you have detailed seems possible.

Though, I arrive at different conclusions based upon the following;

Did an Erase and Clean install 10.13.2 Dec 2017 and added 10.13.2 Supplemental Jan 9, 2018 - no issues. Then did an Erase and Clean install 10.13.3 Feb10, 2018 and added 10.13.3 Supplemental Feb 20, 2018. At that point still no Signpost ** issues in Console. Then upgraded to 10.13.4 Mar 30, 2018 and immediately started the Signpost** issues flooding Console. Worked with Apple April 4, 2018 to fix with Data Capture for 7 days and nothing. Thinking that the upgrade from 10.13.3 or 10.13.3 Supplemental may have been the root cause did an Erase and Clean install 10.13.4 April 2, 2018 and the Signpost** issues in Console are still flooding in. That would indicate, to me, something NEW was introduced in 10.13.4 causing all this. Have read elsewhere that 10.13.4 Metal 2 was rewritten to support eGPU and that Skylight is part of all this eGPU support.

What I do sense is this issue, Signpost** has striking similarities to the “13 Month Out of Bounds” errors in Console in Oct, Nov or Dec 2017. Sloppy coding, rushed to market, resources spread too thin or not enough $$ in the bank? Not like my first Apple with Tiger on PPC days for sure.