Процессы, выделяющие избыточное дисковое пространство для (удаленного) файла.xsession-errors
Мой корневой диск переполнен до краев из-за, я подозреваю, дискового пространства, заблокированного всплывающим файлом.xsession-errors. Раздувание вызвано запущенными процессами, которые держат файл ошибок открытым и выгружают в него данные, т. Е. PID из нескольких различных приложений, например, хром является самой большой причиной. Я подозреваю, что это так, потому что lsof | grep Удаленный возвращает строки, такие как:
chromium- 27607 user 2w REG 8,1 1809493864448 108527952 /home/user/.xsession-errors (deleted)
chromium- 27762 user 2w REG 8,1 1809493864448 108527952 /home/user/.xsession-errors (deleted)
Суть в том, что у меня есть задание cron для удаления файла home/user/.xsession-errors` в соответствии с предлагаемым решением этой проблемы. Вы можете вообразить, как быстро разворачивается эта ситуация, когда хром открывает множество процессов! Я использую 64-битную машину UBUNTU 12.04 со следующей конфигурацией HD (EXT4):
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8T 34G 1.7T 2% /
udev 12G 4.0K 12G 1% /dev
tmpfs 4.8G 1.2M 4.8G 1% /run
none 5.0M 16K 5.0M 1% /run/lock
none 12G 2.1M 12G 1% /run/shm
/dev/sde1 1.8T 450G 1.3T 26% /media/SEA2T
/dev/sdd1 2.7T 201M 2.6T 1% /media/BUFF3T
/dev/sdb 3.6T 118G 3.3T 4% /media/INDAR
/dev/sdc 3.6T 3.0T 469G 87% /media/ALAYA
Что я сделал до сих пор, чтобы решить напрасно:
- Можно ли вернуть это пространство? Очевидно, не в моем случае, хотя другим удалось усечь файл, чтобы освободить диск.
- Поскольку это кажется своего рода виртуальным явлением, при котором реальные файлы не являются виновником, перезагрузка была для меня подходящим вариантом.
- Как сделать так, чтобы это больше не повторилось? Я до сих пор не знаю. Текущий обходной путь - установка
ERRFILE
переменная в файле/etc/X11/Xsession
в/tmp/$USER-xsession-errors
чтобы выяснить, что сбрасывается в этот файл ошибок. Я ценю любые предложения относительно того, как раз и навсегда разобраться с убегающим файлом xsession-errors! Заранее спасибо.
1 ответ
Вы можете получить доступ к файлу через ls -l /proc/<PID>/fd/*
(опасно), и как только вы определили номер fd, обрежьте его с помощью truncate /proc/<PID>/fd/<fd> --size 0
(еще опаснее). Это альтернатива перезагрузке или уничтожению процесса. Однако трудно сказать, что произойдет при последующих записях в такой изуродованный файл.
Что вы действительно должны сделать, это выяснить, что пишет в этот файл и почему, и предпринять все необходимые шаги, чтобы помешать ему сделать это. Даже игнорируя проблемы с хранением, запись журналов отладки обходится дорого и снижает производительность. Таким образом, вы должны найти основную причину.