Итак, после включения костылика количество мёртвых записей кардинально поубавилось и за пределы полутора сотен не вылезает. Но проблемы на этом не закончились.
По работе надо частенько из журнала запросов или консоли браузерных девтулзов копировать JSON'ы. Всё хорошо, пока оные не достигают внушительных размеров, проблемы начинатся уже где-то с 250 килобайт, а JSON'ы бывают и куда большими. Копирование зачастую происходит не до конца. Из-за этого я начал пропускать JSON'ы через преттифаер: pbpaste|jq . > /tmp/%filename%. Если обкоцанный — он ругнётся. Размер обкоцанного буфера постоянно разный, часто проскакивают 2¹⁸ и её суммы, но бывают и какие-то совсем странные числа.
Сначала я пенял на место на системном разделе. Менеджерами буфера обмена из соображений секурности не пользуюсь, то есть копирование происходит напрямую из процесса в процесс. Однако с какого-то предела жирности в /tmp кладутся файлы clipboardcache-*. В любом случае, эти файлы тоже оказываются недописанными, при том, что места полгига там есть.
Сегодня при подобных попытках успешно записать содержимое буфера обмена в файл браузер-источник вообще начал эпизодически падать. Тут-то я и обратил более пристальное внимание на сабж. Количество записей, как и обычно, не смутило. Решил посчитать размер.
root@localhost:/home/bodqhrohro/Загрузки# ipcs -a|grep dest|col5|paste -sd+|bc
606731544
ipcs -p, вычисляю первого попавшегося жиробаса на 64 МБ. PID создателя принадлежит dunst. PID последнего доступателя — некий 27778, которого и след давно простыл. Перезапустил dunst, смотрю — там ещё куча записей от мёртвого 27778. С emerald, например, расшарено 8 МБ — иконка, что ли? Главное, этих почищенных 64 МБ уже хватило, чтобы чтение буфера обмена успешно отработало с первый попытки.И что, спрашивается, с такими мёртвыми жиробасами делать? Если определённо мёртвые записи я чистил смело, то тут очкую — один из использующих процессов-то ещё жив.