Никакой/var/log/syslog файл после перемещения/var/log к tmpfs

Для предотвращения бесполезной записи к моему 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 смонтирован).

Я использую:

  • Ubuntu 14.04.2
  • Ядро 3.13.0-45
  • 7.4.4-1ubuntu2.5 rsyslog
4
задан 4 March 2015 в 13:04

2 ответа

Необходимо создать те файлы в /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 на завершении работы при необходимости в них, чтобы быть персистентными между системными перезапусками.

0
ответ дан 1 December 2019 в 10:05

Перемещение чего-либо в /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 была часть /.

3
ответ дан 1 December 2019 в 10:05

Другие вопросы по тегам:

Похожие вопросы: