/dev/mapper/vg00-var maxing out

Это работает для меня, используя параметры Mint 17:

gsettings set org.gnome.libgnomekbd.keyboard «['caps\tcaps: none']»

Вы правы: отсутствует процесс, связанный с системным учетом, это внутренняя функция ядра, которая непосредственно записывается в файл системного учета, который на многих Unix - /var/account/acct . Системный вызов для получения статуса этой внутренней функции ядра отсутствует.

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

На сильно загруженном сервере, и особенно в многопроцессорных системах, 2-й lastcomm может отображать некоторые другие завершенные процессы перед отображением 1-го lastcomm . Это нормально.

Вот моя лучшая функция оболочки, чтобы получить статус учета быть на:

is_acct_on() {
    t=`mktemp /tmp/acct.XXXX`
    touch ${t}
    sleep 1
    x=`find /var/account -newercc ${t} -name "acct" | head -1`
    rm ${t}
    [ -z "${x}" ]
}

использование:

is_acct_on

возврат 0 , если учет выключен

1 , если учет включен.

Похоже, сначала требуется аудит папки /var .

Если вы являетесь системным администратором, то, как правило, не рекомендуется просто устанавливать программное обеспечение и смотреть, что произойдет. Знать/узнавать , что программное обеспечение делает с файловой системой. Существуют также инструменты мониторинга , которые предотвращают такие большие сюрпризы, как заполненная папка /var .

Системные журналы

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

Документы в CMS

Если CMS использует /var/www в качестве места хранения пространства, вам придется самостоятельно проверить, что вызывает увеличение пространства места хранения. Вы должны будете отслеживать его по крайней мере ежедневно (см. выше инструменты мониторинга).

Имеются ли в CMS мультимедийные файлы? Говорили ли людям, что делать с их файлами? Знают ли они, как управлять размером своих документов? Публикация общедоступна? Это умеренно?

Все эти вопросы влияют на то, что вы должны сделать, чтобы предотвратить анархический рост.

Злоумышленники

Если это общедоступный веб-сервер, нередки случаи, когда он оказывается скомпрометированным, хотя я не уверен, что веб-серверы так облажаются. В целом, кибератаки, которые я когда-либо видел, ограничивались превращением сервера в члена ботнета и спам-бота, но такой катастрофический эффект также нельзя исключить.

Если вы не можете позволить себе установку сложного решения для мониторинга, вам придется хотя бы проверить используемое пространство:

du -hsx /var/www/*

-h for a human-readable report
-s for a brief summary of all files and subfolders
-x to stay on the same volume (in case other mounts under exist `/var/www`)

Какие файлы также сохраняются здесь?

Нужны ли они?

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