Если это баг извесный, то побороть его можно неготорыми способами.
1) Парсинг - простой скрипт с определенной переодичностью проверяет размер лога и если больше нужного значения или подрезаеться или архивируеться и сохраняеться (не пробовал, но навериника можно реализовать это прикрутив лог через syslogd)
2) Если содержимоего лога не важно - включить квоты на диске, запустить процесс под отдельным юзверем и на юзвера установить "жесткую" квоту.
3) Разобраться - 87 гиг - без включения отладочной инфы в лог забить очень тяжело - отключить вывод отладочной инфы - лог наверника перестанет так расти
4) А нужныли вообще от него вам так эти логи?
на все вопросы: все дело в проге , никакой отладочной инфы не включено. Можно сделать как предлагают разрабы кутима вместо исправления ошибки - сделать симлинк этого файла в девнулл, в нормальном состоянии этот файл не превышает нескольких десятков килобайт, и перезаписывается при каждом старте системы. так что предложения
1 и 2 слишком "хороши" .
3 - "наверняка" не работает, это логи краша x-server , не отключабельны
4 - мне не нужны, никому не нужны, тем более что там повторяющаяся строка за строкой до упора в размер ФС информация
Warning: QNativeSocketEngine::read() was called not in QAbstractSocket::ConnectedState or QAbstractSocket::BoundState это баг
пока решение: ln -s /dev/null ~/.xsession-errors не поможет, старт GDM перезапишет ссылку,
пока решение добавил в крон ежечасно
rm ~/.xsession-error