Systemuiserver mac os ��� ��� �����

Question: Q: What is SystemUI Server

General internet search came up with various articles about a problem with this application causing issues — at other sties — but here it seems to just be in logs or listings.

Since I started an a very intense housekeeping on files — and adding text to photographs not in IPHOTO — have experienced power up issues.

Have done a number of things including putting my folders in the private section of spotlight to stop excessing indexing, also removed Wacom pad and software as pad has seen better days & purchased new Mouse -same model as came with late 2008 Mac Pro that is running Snow Leopard.

I did replace the clock battery — I shut down after use.

I believe I have jumped the gun when the system is on grey or blue screen — so that may have added to some issue with finder spotlight indexing —

Yesterday evening I did notice TimeMachineNotifier running and disk IO while I was not doing anything —so let it run for awhile — but with no stopping in sight had to shut down. This morning it was a slow startup (I waited patiently) but trying to run even activity sticky — and the monitor had some freezes — patience again and was able to force quit then restart — guess what — all peachy on the restart — only thing running SystemUIServer — not taking much memory but wondering if my deleting of some documents — has triggered a unix job to compress or clean up the disk.

Posted on Mar 2, 2016 6:57 AM

All replies

Loading page content

Page content loaded

Try running this program and then copy and paste the output in a reply. The program was created by Etresoft, a frequent contributor. Please use copy and paste as screen shots can be hard to read.

Mar 2, 2016 8:17 AM

Try running this program and then copy and paste the output in a reply. The program was created by Etresoft, a frequent contributor. Please use copy and paste as screen shots can be hard to read.

Actually have run it a number of times and it come out with no problems.

This power up — worked fine — just hit the power button.

Although I only deleted about 2 gigabytes of information — I did spend time refiling — and in the case of photographs opening adding box with text and saving — so that would have possibly caused some fragmenting of the disk — along with the spotlight finder indexing going into berserker mode — never really used it so never saw that detail on the amount of detail it was trying to keep.

Have had experience with proprietary mainframe software — doing some housekeeping that didn’t show in its job lob — but took 45 minutes every night (based on logs — as looking at the job while it ran just looked like it is sitting there) so wondering if the cleanup triggered one of the UNIX cleanup jobs.

Oh — after a slow power up rather than fighting with the monitor getting stuck — immediately doing a restart clears the problem.

I have seen this same issue through El Capitan so I feel there is a trigger for whatever is running — the logs seem to show nothing out of the ordinary — as I looked at older logs for comparison (if they exist) and they have the same stuff.

Источник

Почему SystemUIServer вызывает высокую загрузку процессора?

Процесс SystemUIServer занимает 30% моего процессора. Поиск вокруг показывает ошибку летнего света Snow Leopard, которая решается путем удаления часов из меню. Я нахожусь на льве, и я пробовал это без успеха. Любые идеи о том, как исправить это?

4 ответа

Такая же проблема. Проблема вызвана сторонним виджетом, который использует Интернет. Для меня проблема с Dropbox была проблемой. Если dropbox обновляет мои файлы, systemyserver продолжает использовать большой объем процессора. Единственное решение — заставить его выйти (используя терминал или монитор активности) или отключить сторонний виджет.

Похоже, на самом деле есть несколько способов решить эту проблему.

У меня была такая же проблема, и сегодня я также заметил, что мои часы не показывали правильное время примерно через 2 часа, и когда я нависаю над часами, я получаю вращающийся пляжный мяч.

Итак, я нашел из этой статьи , что вы можете просто убить SystemUIServer процесс, и он просто перезапустится, и все снова будет хорошо.

Чтобы убить процесс SystemUIServer, вы можете просто открыть Activity Monitor, Filter by Process Name или% CPU (так как это, скорее всего, самый высокий пользователь CPU), затем выберите «SystemUIServer» и выберите «Quit Process» из параметры в верхней части окна (кнопка, которая выглядит как знак остановки).

Как только вы убьете этот процесс, OS X просто повторно инициирует процесс, и вы должны вернуться в нужное русло. Однако это кажется лишь временным решением, и вы можете столкнуться с ним снова.

Итак, для более постоянного решения (если вы не боитесь рисковать на конечную землю), попробуйте выполнить процесс, описанный в этой статьи , которая была предоставлена ​​ Джошуа Тейлором , где вы добавляете задание cron для OS X, которое перезапускает SystemUIServer в начале каждого другого часа (автоматизация решения выше для этой проблемы):

Откройте терминал (/Applications/Utilities/Terminal.app).

.. и нажмите enter.

Нажмите букву «a» на клавиатуре.

Введите следующие данные, используя вкладки для больших разделов:

0 */2 * * * killall SystemUIServer

Нажмите клавишу эвакуации на клавиатуре.

.. (это двоеточие, w затем q) и нажмите enter.

Это завершит процесс только в том случае, если время процессора превышает 5 минут:

*/15 * * * * [[ «$(ps -e | grep SystemUIServer | awk ‘‘)» > 5:00.00 ]] && killall -kill SystemUIServer

Если вы не знаете, как использовать vi, вы можете изменить crontab с помощью EDITOR=nano crontab -e .

Недавно у меня была такая же проблема на Mac 10.0.5 с установленной DropBox. Обновление текущей версии DropBox (2.6.2) помогло значительно, но не полностью. Вместо того, чтобы система замедлялась с вращающимся радужным колесом, а SystemUIServer сообщал о 98% -ном использовании процессора (несколько раздражающих) раз в день, сейчас он сокращается до двух раз.

Источник

Systemuiserver mac os ��� ��� �����

iStat is a great program for keeping track of your system by displaying menulings showing CPU usage, memory usage etc. In Mac OS X menulings (also called menu extras) are managed by a program called SystemUIServer.

iStat appears to have a memory leak where over time, the REAL memory used by SystemUIServer grows basically without bound. Memory usage that should be around 40MB balloons to 300MB then to 1.3GB over a few weeks of never rebooting. This would be bad enough if it was the virtual address space that was being used up this way, but this is real memory, causing real memory pressure and real swapping.

Obviously the ideal would be for Bjango to get on the case and fix this bug. Since they appear unwilling to do so, I have come up with a workaround.

The following facts are relevant to the workaround.

• A separate copy of SystemUIServer runs on behalf of each user, owned by that user, when the user has a GUI login. This is very convenient because it means we can kill this program without requiring passwords and suchlike.
• SystemUIServer appears to have been very nicely cordoned off by Apple from the rest of the system so that you can kill it at any time and nothing bad happens. The menulings all disappear, then launch restarts SystemUIServer, and the menulings all reappear (in a much smaller memory environment).
• So the simple one-off solution to the problem is to type in Terminal:
  killall SystemUIServer. And this works, but only once — you will need to do it again in a week or so.
• The possibility I chose is to have launchd execute this command once a day, at a time when I’m probably not using the machine, namely 4:00am. (If your machine is asleep at that time, launchd in Snow Leopard performs the task when the machine is wakes up, and this works out OK — we see just one more flash in the UI as the menulings are killed then restart, to accompany the various other flashes in the UI that occur when a wake occurs.

To make this all happen is not too hard. You need to create a launchd script, I called mine my.SystemUIServer_cleaner.plist, and populate it as follows:

Put this in /Library/LaunchAgents, and make sure it is owned by root:

cd /Library/LaunchAgents
sudo chown root:wheel my.SystemUIServer_cleaner.plist

This file will only be noticed by launchd and kick in automatically when you logout then login again. If you don’t want to do that, but do want it to start working right away, you can manually tell launchd about it using:

sudo launchctl load /Library/LaunchAgents/my.SystemUIServer_cleaner.plist

[crarko adds: I haven’t tested this one. This would be applicable to managing runaway SystemUIServer memory in general if you observe it, and not just for iStat. It’s also a good example of a simple launchd script.]

Источник

Моя борьба с PTPCamera или увлекательная история о реверсинге для самых маленьких

Почти все продвинутые зеркальные камеры, а также некоторые правильные мыльницы, позволяют управлять собой с компьютера. Программное управление камерой дает интересные возможности, например: съемка time lapse video, сопряжение камеры с микроскопом, эксперименты в области компьютерного зрения. Для управления камерой вендоры предоставляют свои проприетарные SDK, которые обычно работают исключительно под Windows и поддерживают камеры только в рамках определенной линейки (например у Canon есть аж 4 несовместимых между собой SDK). Какое счастье, что есть достойная открытая альтернатива — проект gphoto.

Прямо сейчас gphoto поддерживает 1598 моделей камер и список постоянно растет. Проект собирается под все UNIX-like ОС, включая Linux и Mac OS X. Съемкой можно управлять как при помощи command line утилиты, так и из своей собственной программы, используя библиотеку libgphoto. Доступны биндинги для разных языковых платформ, включая node.js.

В современных ОС присутствуют встроенные средства для работы с цифровыми камерами — как правило под «работой» подразумевается только выгрузка фото из камеры. Эти встроенные механизмы препятствуют работе gphoto, так как захватывают USB устройство в эксклюзивном режиме. Особенно интересно дела в этом плане обстоят в Mac OS X — ОС не предоставляет никаких штатных возможностей для отключения, но при этом система поддержки цифровых камер легко поддается реверс инжинирингу.

Скрипты для блокировки запуска PTPCamera на github.

PTPCamera

Интернет советует выполнить команду killall -9 PTPCamera (убить процесс PTPCamera) после подключение фотоаппарата для нормальной работы gphoto. Это в самом деле помогает, однако каждый раз при подключении камеры процедуру приходится повторять заново. Разумеется, программу PTPCamera можно просто удалить, но мне хотелось обойтись менее радикальным решением.

В общем, требовалось понять механизм запуска PTPCamera, и максимально корректно отключить эту функцию.

О захвате изображений в Mac OS X

Согласно имеющимся источникам [1,2], инфраструктура захвата изображений в Mac OS X устроена следующим образом.

На вершине стека расположены приложения, с которыми непосредственно взаимодействует пользователь (ex: iPhoto).

В самом низу расположены приложения для управления устройствами, к числу последних относится PTPCamera. Приложения для управления устройствами ( MassStorageCamera.app , PTPCamera.app , TWAINBridge.app и тд.) живут в системных папках /System/Library/Image Capture/Devices и /Library/Image Capture/Devices .

Посередине находится коммуникационный слой, который организует связь между верхним и нижним уровнями. Любопытно, что несколько пользовательских приложений могут использовать одно устройство совместно, а также возможна прозрачная работа с устройствами по локальной сети.

Кто же запускает PTPCamera?

Попробуем определить механизм запуска PTPCamera, и для начала определим родительский процесс.

Итак, мы видим что PTPCamera запущен процессом launchd. В Mac OS X launchd — это универсальная запускалка для системных и пользовательских демонов. В системе запущено по экземпляру launchd для каждого активного пользователя. Launchd пользователя root выполняет те же функции, что init в традиционных UNIX системах.

Кроме демонов, laucnhd также запускает графические приложения по команде других программ. PTPCamera — это именно последний случай, как можно убедиться по ID задачи в launchd, об этом нам говорит [префикс].

Итак, мы знаем что PTPCamera был запущен процессом launchd, по команде некого приложения X.

Включим логирование launchd ( launchctl log level debug ), и спровоцируем повторный запуск PTPCamera.

По умолчанию, на каждый процесс в системе выделена квота в 500 записей в логе в секунду. Сообщения, не уложившиеся в лимит, отбрасываются. Настроим отдельную сборку отладочных сообщений для обхода лимита.

Добавляем в файл /etc/syslog.conf строку
и информируем демон syslogd о необходимости перечитать настройки
Анализируем полученный файл debug.log . Находим искомое:
Запрашиваем у launchd информацию о com.apple.SystemUIServer.agent :

Теперь мы знаем, что «виновник» запуска PTPCamera — это SystemUIServer , ни много ни мало.

Ковыряем SystemUIServer

Имеется подозрение, что искомый функционал находится не в самом SystemUIServer , а в одном из прилинкованных фреймворков:

В этом списке главный подозреваемый — ICANotifications.framework . ICA — это сокращение от image capture, тот же акроним используется в публичных фреймворках для захвата изображений.

Изучаем ICANotifications.framework

Лирическое отступление. Исполняемый файл состоит из кода и неизменяемых статических данных (разные константы, таблицы, и тп.) Особый интерес представляют строковые константы. Извлечь их можно при помощи команды strings .

Запускаем strings /System/Library/PrivateFrameworks/ICANotifications.framework/Versions/A/ICANotifications , и наслаждаемся результатами:

Итак, рабочая гипотеза — библиотека работает с SQLite базой данных, наиболее вероятно, что это файл com.apple.ImageCaptureNotifications.DeviceDiscoveryDatabase в /Library/Caches .

Видно, что в конец имени ( com.apple.ImageCaptureNotifications.DeviceDiscoveryDatabase.501 ) дописывается ID пользователя, для каждого пользователя поддерживается собственный файл. Из содержимого понятно, что база задает список соответствий класса устройств и управляющей программы, которую нужно запускать при обнаружении устройства.

Редактирую базу данных, мы отключаем запуск PTPCamera для любого выбранного пользователя, это однозначный успех!

При необходимости вернуть все обратно, откатываем изменения, или просто удаляем файл бд (название папки /Library/Caches сообщает нам, что ОС при необходимости может перегенерировать содержимое).

Источник