1. I was able to update the relevant preferences in that file to remove the system clock. However, the SystemUIServer application needs to be restarted so that the new preferences can be reloaded and the clock can be removed. Here is the code I have used to restart SystemUIServer.
2. Defaults write com.apple.screencapture type “type” && killall SystemUIServer For example: defaults write com.apple.screencapture type JPG && killall SystemUIServer How To Change The Default Screenshots’ Filename As I mentioned above, your screenshot will be saved to your desktop by default, with an auto-generated name, like “Screen Shot.
3. I've recently had the same problem on a Mac Pro running system 10.7.5 with DropBox installed. Updating to the current version of DropBox (2.6.2) has helped considerably, but not completely. Instead of getting a system slow down with a spinning rainbow wheel and SystemUIServer reporting 98% cpu usage multiple (annoying) times per day, it is now.
4. Removing the drop shadows from your Mac screenshots is pretty easy and can be done using a command in the Terminal app. Launch the Terminal app on your Mac. Type in the following command into the Terminal window and hit Enter. Defaults write com.apple.screencapture disable-shadow -bool true; killall SystemUIServer.

• Systemuiserver Mac Not Responding
• Systemuiserver For Macbook
• Systemuiserver For Macbook Pro
• Systemuiserver Mac

Recently, the SystemUIServer process on my MBP running macOS Sierra has started “eating” a lot of CPU, slowing down the whole machine, even making the clock in the top menu bar stop working properly. It usually started using one-digit percentages of the available CPU power, then growing to 10%, 15%, 20%, up to well above 60%, sometimes even 80% and more! It wasn’t a steady growth – it sometimes shrank again, just to grow even further.

The only apparent remedy was to kill the SystemUIServer process (e.g. using the Activity Monitor) from time to time (i.e. every 30 minutes -> there are also scripts to automatically restart SystemUIServer). Its CPU usage then reset to a low one-digit number.

Taking a closer look at the process in the Activity Monitor, I then noticed that the number of (used) ports (so-called “Mach ports“) by the process were steadily growing, once SystemUIServer was started. This was weird, pointing to some kind of leakage. Typically, for a CPU load of around 50%, more than 5000 Mach ports were used.

By coincidence, I then noticed that, unlike expected, my MBP wasn’t actually using Ethernet, but only WiFi. Further investigation then hinted that the according Gigabit Ethernet port on my HP 1810 switch was apparently malfunctioning (or even dead): In the macOS Network Preferences, the Thunderbolt-Ethernet connection was constantly shown as red/disconnected, although the OS was apparently trying to establish a connection again and again (and failed). First, I even suspected a problem with the Thunderbolt-Gigabit-Ethernet adapter itself (it wasn’t the problem here, the adapter seemed to work fine with another Mac and connection).

The solution to this problem thus was:

I am not sure if this qualifies as a hint, but I want to share some experiences I had with the SystemUIserver. My system is a DA G4 with 768Nb of ram, 10.2.2 installed. It is always on. I've noticed since running 10.2, the mac slows down for no reason after a while. Sometimes it occured after a few days, sometimes after two or three weeks. Converter to mov for mac.

• Connect the Ethernet cable to another, working Ethernet port: Now the SystemUIServer process consumes less than 0.1% CPU again and roughly 400 ports only, both with and without additional WiFi.
  Note that both the problem and this solution are reproducible.

Lessons learned:

• Sometimes, very unexpected, seemingly unrelated and “small” problems can have big (negative) effects.
• Sometimes you need a bit of luck to find the cause of a problem (a web search didn’t bring up the above hint, rather suggested updating or removing faulty apps, buggy extensions and menu widgets. I thus already tried removing or updating some of the suspected apps, extensions and widgets.)
• Ports of HP 1810 switches can actually break/fail! Remember the saying: “I got 99 problems, but a switch ain’t one!” – well, in this case, the faulty switch was actually part of the problem and even the initial trigger of the problem! Also remember that HP offers a lifelong warranty on its (good ol’) 1810 switches.
• Extra points for you, further research: The fact that the SystemUIServer allocates more and more Mach ports if there’s a malfunctioning Ethernet port (i.e. faulty Ethernet connection or faulty handling of a faulty Ethernet connection by the Thunderbolt-Gigabit-Ethernet adapter) is hinting that this might be an attack vector for a (new?) DoS attack. Perhaps not an easily exploitable one (on the Ethernet or MAC layer, even), but it’s nonetheless something that should actually be handled gracefully by SystemUIServer, not leading to more and more CPU and system resources being consumed.
  If you have time to research this further, let me know about your findings!

are you sure it's not another menubar app (e.g. google notifier) that is causing your systemuiserver process to leak memory?
i use istat menus 3.05 and my mac has been up for nearly 3 weeks (never sleeps) and systemuiserver is only 150MB. i have 6 other apps that run in the menubar as well, so 150MB doesn't seem unreasonable. it's second only to kernel_task in terms of real memory usage by the system.

I'm also not seeing this memory leak with iStat v3.05 -- I'm wondering if the original poster actually submitted this as a bug report to them? They have a nice web form for contacting them at:
http://bjango.com/contact/
I mentioned this thread to them using that web form so maybe someone from Bjango will show up here to comment..

I'm seeing the same behavior. My SystemUIServer was at 1.5 GB (that's not a typo, GB) this morning. It probably depends on which menubar widgets you're using. I have network, CPU, date, disk and battery running. I haven't tried mix and matching to see which might be causing the problem.

I have seen this memory leak when I was using 2.x. I fiddled around with the various monitors to try and figure things out. It's not enough to just use or not use some of the monitors. For example, the rate of leak (if it happens for a particular monitor) can be different depending on the display style you choose for that particular monitor. i.e. Using a percentage display for CPU vs using the history histogram.
Since going to 3.x I have not seen the leak no matter which style or monitors I use. The computers used for observation are on for as long as possible - years if possible, but with some scheduled down time.

I haven't tested the LaunchDaemon, but I have little doubt it would work -- I found this page googling about SystemUIServer and memory usage, and can happily report that 'killall SystemUIServer' does indeed (temporarily at least) solve my problem.

I had been a little suspicious of iStat Menus (which I'd rather not forgo -- too useful), as it was the only non-Apple thing I saw referenced in SystemUIServer's open files list in Activity Monitor.

Thanks, name99, very much, for doing/presenting the research that SystemUIServer can safely be killed (and will auto-restart), as I was not looking forward to having to restart my MBP occasionally just to get SystemUIServer to release its excess memory.

And I was a little astonished to find precisely the answer I needed, written up on the very morning I went looking for it. BTW, I also came across Tuning Mac OS X Performance, which suggests that 3rd-party menu extras are top suspects in excess CPU usage by SystemUIServer as well:

Third-party menu extras that use an active Internet connection can result in very high CPU usage if the network connection becomes busy or blocked. The chances of this increase if you are simultaneously using streaming media and a menu extra that requires an Internet connection.

When iStat Menus 3 first came out, I tried it and then subsequently noticed my machine became very boggy within a few days. A reboot (I know, barbaric) would fix the problem temporarily, but it would return. I reverted back to iStat Menus 2 and the problem went away.
I've been watching the updates to see if they have fixed any performance issues that would be related but haven't seen anything.
Your problem and fix sounds like the same thing, but my trial version of 3 has long since expired.

With the latest version, I've had no problems with memory usage. I'm using the clock and calendar widget, load widget, temperature and network usage widgets. Currently using 48.5MB real memory, and 78MB virtual memory. I've not noticed it slowing anything else down either.

Obviously the ideal would be for Bjango to get on the case and fix this bug. Since they appear unwilling to do so, …

Did you report it to them, name99? Not everyone leaves their computer running for weeks without rebooting.

Don't forget to send them evidence that the leak is from iStat Menus, not one of the built-in menu extras or another third-party SystemUIServer plug-in or application's status item. Just because you're seeing a leak doesn't mean they would be.

I currently have a 28 days uptime; and the SystemUIServer requires 8.14 MB. (960MB virtual memory are assigned to it, but that value strongly depends on the free space you have on your system drive; and I have a lot free there).
I don't use iStat, obviously.
Perhaps you should try an alternative, like MenuMeters.

Systemuiserver Mac Not Responding

I, too harbored deep suspicions about iStat 2's resource usage, but version 3 seems to be much better behaved, so I have no regrets paying for the upgrade.

(OTOH, I have 8GB of RAM now, so I'm less likely to notice these problems, even with a few dozen tabs open in Chrome, plus Safari, Mailplane and Firefox, not to mention my VMware XP machine running all the time. The thought of a 16GB iMac makes me drool.)

My current uptime is 36 days and SystemUIServer is using only 53MB of real memory, which seems reasonable with all the other menu thingies I have (it's a constant struggle weighing their relative merits against available screen space). But I'll keep this hint in mind if I see it creeping into the stratosphere. I like easy fixes. :)

Now, if only kernel_task could be reset without disrupting the whole boat..

Advanced mac cleaner for free. I ran into the same problem a few months ago. I noticed that my laptop wasn't waking, and I would resort to power cycling my unit. I let my unit sit for a couple of hours with the lid open, and the OS finally came back. I found SystemUIServer taking huge amounts of resources in Activity Viewer.
What worked for me was to: put my unit in target mode, mount it on another computer, and remove all of the cache contents. I removed:
rm -rf /Volumes/My Laptop/System/Library/Caches/*
rm -rf /Volumes/My Laptop/Library/Caches/*
rm -rf /Volumes/My Laptop/Users/username/Library/Caches/*
I'm assuming there was some corrupt data in cache SystemUIServer was gnawing on.
YMMV

Some people have complained about my blaming iStat menus for this. Let me say:
(a) I love iStat menus. If I didn't I would just disable it.
(b) Although I aggressively report bugs (I expect Apple are sick of me) I personally have not reported this one to Bjango. When I was doing research on what SystemUIServer did, and why it was growing so large on my machines, I saw many reports of iStat menus, dating from a long time ago; and I figured that Bjango simply knew about this. Fair enough, it's a big internet, so I will submit a bug report to them.
(c) Is it fair to blame them? Like most people, I'm not really in a position to track this down scientifically --- that's the problem with bugs that take many many days to manifest themselves. I don't use any 3rd party menulings apart from iStat. so it's either them or Apple.
Of course it COULD be Apple, but that seems the sort of thing Apple would catch internally, not necessarily from formal testing but just from engineers noticing huge SystemUIServer memory usage on various machines (home machines, work machines, spouses machines). Back when I worked at Apple, for example, I'd certainly write up a bug for anything unexpected I saw on a machine, my own or someone else's.
As for reproducibility, I have a very customized version of iStat, in that the display of pretty much everything has been changed from the default way Bjango has it set up. It is certainly possible that it is only if you use CPU display with custom colors AND aggregating CPUs (or whatever) that the bug is triggered, which is why some people don't see it.
(d) I used MenuMeters before iStat Menus, and found it did the job, but iStat Menus is substantially richer in what it displays, and I have come to really like having easy access to the info it presents.

Does anyone know if this memory leak is also present in the iStat dashboard widget?

Regarding the comment implying that Bjango are unwilling to fix this, I understand your frustration, and there are a lot of companies that have really poor customer service, don't fix bugs, and don't respond to emails.
This is not the case for Bjango. I contacted them about this bug. They very quickly responded and explained that they are aware of it and working on it.
There are LOTS of companies out there with good customer service. Bjango have always responded to my inquiries. Another good company is the Omni Group. Also, Crucial and Kingston. How about Apple (when you have AppleCare anyhow). Newegg, and even Amazon. On the other hand, I'll never again do business with OCZ or MSI, and I avoid Chase (the bank that handles the Amazon VISA card) like the plague.

Thank you.
We're definitely watching this one closely and we've been in contact with name99 to see if we can get some more info. There were some memory issues in older versions of iStat Menus. Version 3 fixed quite a few bugs and memory handling. We don't have any known memory leaks in version 3, but we're doing what we can to investigate to be sure everything's ok (and if it's not, we'll make every effort to fix any bugs).
Also, thanks for mentioning us alongside other great companies like Omni, Kingston, Apple etc. There is definitely one way we're a little different: We're smaller than all of those companies. That means we're very agile and if you receive a reply to a question, it's either from our full time support person or from one of the people building the app (please be nice, we do everything we can to make great apps!).
On a side note, iStat Menus 3.1 will be released in the next few days. As always, any bug reports are welcome: http://bjango.com/contact/

Systemuiserver For Macbook

I've twice reported a similar iStat 3 issue whereby the WindowServer process would gradually start eating up CPU cycles within a day after booting and I've had not a single response. The little bug report form doesn't look like it would be able to handle pasting in my entire system.log so I was hoping someone at Bjango might actually request that or any other pertinent files via email. Considering that I gladly paid for the functionality of this app and that it has been pretty much useless since, I would appreciate at least being given the opportunity to help the developers nail down the issue that's affecting my system.

Systemuiserver For Macbook Pro

Systemuiserver Mac

I used to use iStat, but switched to freebie MenuMeters and have been VERY pleased. Seems to show everything that iStat showed; doesn't seem to have any hidden gotchas that need such work-arounds. And it's free. :-)