Для предотвращения бесполезной записи к моему SSD, я переместился /var/log
(и /tmp
) к RAM через /etc/fstab
:
cat >> /etc/fstab <<'EOT'
tmpfs /tmp tmpfs defaults,size=1g 0 0
tmpfs /var/log tmpfs defaults,nosuid,nodev,noatime,mode=0755,size=5% 0 0
EOT
Но с тех пор я имею нет /var/log/syslog
файл.
Я думал, что это было потому что /var/log
еще не смонтирован когда rsyslogd
запускается, но это все еще не работает, вручную перезапуская сервис (когда я уверен /var/log
смонтирован).
Я использую:
Необходимо создать те файлы в /etc/rc.local
файл как этот:
# Restore tmpfs directories for logs.
# Extend the following directories to your needs according to installed packages
for dir in apparmor apt cups dist-upgrade fsck gdm installer samba unattended-upgrades upstart ;
do
if [ ! -e /var/log/$dir ] ; then
mkdir /var/log/$dir
fi
done
# Restore syslog files
for file in debug mail.err mail.log mail.warn syslog ;
if [ ! -f /var/log/$file ] ; then
touch /var/log/$file
chown syslog:adm /var/log/#file
fi
done
# Set owners for the newly created log directories
chown root:adm /var/log/samba
Выше сценария идет перед строкой:
exit 0
Этот сценарий создает те необходимые каталоги, и файлы в системе запускаются. Можно также дополнительно синхронизировать те каталоги с помощью rsync
на завершении работы при необходимости в них, чтобы быть персистентными между системными перезапусками.
Перемещение чего-либо в /var
к tmpfs плохая идея в этой точке, потому что ни Ubuntu, ни любой другой главный дистрибутив Linux не поддерживают ее в данный момент. Это также имеет недостаток, чтобы занять оперативную память и потерять все предыдущие файлы журнала, который препятствует диагностике проблем. Твердотельные диски действительно не являются настолько тонкими когда дело доходит до циклов записи, и несколько файлов журнала не приводят к достаточному количеству данных и операций записи для сокращения продолжительности жизни SSD значительно. Очень немного SSD перестали работать из-за исчерпания цикла записи.
Я подозреваю это /var/log/syslog
все еще существует, но только в корневой файловой системе, потому что rsyslog
запускается прежде /var/log
смонтирован. Когда Вы монтируете другую файловую систему в /var/log
, его предыдущее содержание скрыто внизу.
Как обходное решение можно связать корневую файловую систему где-то в другом месте, которая позволила бы Вам осматривать ее содержание, незатененное другими точками монтирования:
sudo mkdir -p /mnt/root
sudo mount --bind / /mnt/root
Необходимо теперь видеть другое содержание в /mnt/root/var/log
.
P.S.: Если у Вас есть диск внутреннего жесткого диска в Вашей машине в дополнение к SSD, можно смонтироваться /var
оттуда. Это - то, что я и многие другие люди делаем и не главным образом из-за опасений по поводу циклов записи. Главная причина всегда была, что дефектная программа может случайно записать "кучу" (журнала) данные к /var
и никто не заметил бы, пока файловая система не была полна, в которой точке будет трудно облегчить ситуацию, если /var
была часть /
.