hangs on "signpost_notificationd Skylight"

sorry for late reply...issue closed by myself because Apple was not satisfied with by error logs and was pushing issue back at me,to re-format bug report.... so I closed it, seems 3 of my recent Bug reports were not up to their (Apple) specs, all were console errors...month13 out of bounds, signpost_notifcationSkyLight, andTouch Bar Ui errors Frustration on my part

Same here, also when it goes to sleep while you're running some processes into the terminal, it will show the apple logo with the progress bar before getting awake. Also Kernel_task will hurt your cpu insanelly whille the sigpost_notifications keep spaming

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.

PatrickMele,

Further, today is last day I can upload from the Capture_Data App Apple sent me last week. Have already uploaded two files one from 12" Retina MacBook and one from Late 2012 iMac both erased and clean install 10.13.4.

Let us see what comes of all this is anything.

Same problem here, I'm using a 2016 MBP with Touch Bar, getting the error "0 is not a valid connection ID" and having some performance hits, Mac becomes unresponsive for a few seconds every couple of minutes. Happening since upgrading to 10.13.4

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 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.

Starting to think along the same lines. They (Apple) have been aware of this since April 4, 2018 when they asked me to Run their Data Capture and upload file for a week from two affected machines.

Will see what happens after 10.13.5 and then decide if changing my ecosystem is worth it. Been with Apple since Tiger on a PPC so loyal but only to a point.

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.

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.

These messages also fill my console (I believe this began after I upgraded to OS 10.13.4 (17E202) on ~May 1. It does not seem to be taking much OS time on my system monitor, but I tried the Force Quit through monitor (P.Phillips suggestion). Indeed, those notifications have gone away. But there are other notifications that I have not seen before. Time will tell. I have to deal with the flood of Norton "symquald" activity first (~400% CPU?) ... (another thread).

iMac 27-inch, Processor - 4.2 GHz i7, Memory - 16 GB; 2TB Fusion Drive ((128GB flash)

I just replaced my iMac 2012 with the Late 2015 version and it's slower. Very slow booting time (up to 2 minutes), Safari taking forever to launch and overall laggy respons to keyboard and mouse. My Console is also flooded with these messages.

This is a clean install of Sierra 10.12.x which I immediately updated to 10.13.4.

(I did make the mistake of not checking the drive and I'm now stuck with the disappointing 1TB Fusion Drive)

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.