Проблема с пакетом deb, нужна предыдущая dependecy

Единственный способ увидеть, что делает один процесс в текущей системе, это отладка этого процесса или отладка всей системы (ядра). Первый довольно прост, и несколько инструментов позволяют сделать это жить на подозреваемом процессе. Можно использовать strace , что выполняет syscalls, и ltrace , чтобы увидеть, какие общие библиотечные функции он вызывает, или даже gdb в целом, чтобы увидеть, какие команды он выполняет в настоящее время. Не то чтобы для последнего вы заморозите этот процесс (в режиме по умолчанию), а также вам нужен исходный код kwin , лежащий в нужном месте, так что gdb сможет загрузить его и показать вам строку, где он действительно остановился. В противном случае он покажет вам только машинную инструкцию со специальными командами.

Для отладки ядра необходима специальная настройка, которая, вероятно, невозможна для уже запущенной системы (если она не была подготовлена для такой установки во время загрузки). Он позволяет вам остановить всю систему локально (kgdb's kdb) или удаленно (kgdb с gdb) и проверить память, регистры и сбросить некоторую полезную информацию, а также разобрать код. Однако для его эффективной интерпретации необходимо знать хотя бы основы x86 asm.

Ядро предоставляет, по крайней мере, псевдофайл/proc/pid/mem, который не читается в обычном режиме, но https://github.com/siblynx/lynxware/blob/master/dumpmem.c является оберткой, которая считывает этот разреженный файл на основе отображений, предоставленных в/proc/pid/maps. Затем можно проверить выгруженный файл с помощью средства разборки. Если вас не волнует состояние процесса, вы можете заставить его сбросить ядро с помощью kill -SEGV pid , но если во время запуска не было разрешено выгрузить файлы ядра ( ulimit -c size ), оно не будет выгрузить ядро, но все равно погибнет, потеряв любые биты информации, которые вы хотите получить.

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

• Имеет ли это предположение смысл?

Я так не думаю. Я бы немного беспокоился, если бы мой fvwm начал вести себя так, или даже twm (если бы я привык), но что касается kwin (и KDE в целом), я ожидаю, что поведение от него, потому что сегодняшний KDE огромный и такая деятельность «нормальная» для него.

Если это было такое поведение, например, с fvwm, я сначала проверил, что процесс '/proc/pid/exe указывает на правый двоичный файл, затем проверил время создания этого двоичного файла с помощью stat -c% z/path/to/binary , а затем заблокировал его, если он был легитимным или устремился к моей всегда готовой kdb, если нет, замораживание системы. Большая часть «потраченной впустую» активности - это ошибки программ или раздувание программного обеспечения.

• Примечание: я скопировал в основном папку /proc/xxx , так что у меня есть довольно много информации.

Это не имеет смысла, поскольку файлы/proc являются чисто виртуальными, и некоторые важные из них (например, псевдофайл mem ) не читаются при запросе в случайном пути.