Здравствуйте, уважаемые читатели моего блога!
Сегодня я поделюсь с Вами небольшой детективной историей из моих трудовых будней. В ней есть невиновный подозреваемый, преступник, а ещё погибнет один конь 🙂 (но обо всём по порядку).
Как-то утром мне написал товарищ — очень важный (потому что единственный) компьютер отказывается пускать пользователей в учётные записи в режимах выше «несекретно». В несекретном режиме всё работает, как и раньше — мистика, не иначе.
Ну и ниже сообщения о помощи, фотография с текстом ошибки — «Xsession: warning: unable to write to /tmp; X session may exit with an error».
Вроде всё написано вполне логично — X сервер не может записывать в каталог /tmp, отсюда все проблемы.
Говорю товарищу проверить свободное место в разделе /tmp и отправить мне вывод команды:
df -hТоварищ отвечает «Ок», и я ухожу на работу. В следующий раз списался с ним в обеденный перерыв — спросил, ну что, разобрался он или нет.
Отвечает, что переустанавливает систему. Написал ему, что «Стоило твоему коню (в лице операционной системы Astra Linux) захромать, ты сразу его пристрелил и купил нового. Как говорит мой отец «красиво жить не запретишь» :-).
Посмеялись, я немного расстроился, что не узнал точной причины ошибки — мне было интересно разобраться с этой проблемой, а точнее, с работой под нулевым мандатным уровнем доступа. Волей вселенной возможность разобраться появилась буквально на следующий день уже на компьютере моей организации.
Компьютер 2011 года с умирающим жёстким диском периодически зависает и запускается с восстановлением файловой системы (утилитой fsck). Я перевёл этот процесс в автоматический режим, так как не всегда бываю на месте, когда это происходит.
Для этого необходимо в параметр «GRUB_CMDLINE_LINUX_DEFAULT» файла /etc/default/grub добавить:
fsck.repair=yesИ выполнить команду:
update-grubЭто удобно, но неправильно. Так мы не сможем контролировать возникающие проблемы — останется только удивляться последствиям (конкретно мой компьютер используется, как почтовый клиент, и в случае повреждения копия информации всегда будет доступна — на рабочих станциях с реальными документами в аналогичной ситуации только вывод из эксплуатации, иначе крайним и останетесь).
Поэтому используем данный метод исключительно как временное решение, но, как говорится, «нет ничего более постоянного, чем временное». В марте этого года купили новый твердотельный накопитель для «экстренной» замены жёсткого диска, но беспощадная бюрократия не даёт нам вставить его в системный блок уже 8 месяцев (документы на него никак не дойдут).
В общем, это была небольшая вставка, чтобы Вы прониклись атмосферой бюджетной организации, а теперь вернёмся к самому компьютеру.
Мандатные уровни доступа выше 0 не работали, сообщения о заканчивающемся месте Zabbix мне не присылал, Fly-dm запустился (обычно, когда заканчивается место — нас встречает чёрный экран консоли). Всё это предавало пикантности ситуации.
В первую очередь выполнил команду:
> /tmp/1Файл создался, раздел /tmp был не переполнен. Ну ладно, посмотрим общую картину:
df -hНу всё ясно, пазл почти сложился. Закончилось место в разделе /var — но почему Zabbix вчера меня об этом не предупредил?
Всё просто — компьютер сегодня завис, оператор его перезагрузил, сработала утилита fsck, которая восстановила файловый дескриптор к /var/log/syslog, но что-то пошло не так, и файл стал весить 40 Gb 🙂
Специально проверил содержимое файла журнала на наличие цикличных сообщений — ничего нет, только крякозябры ближе к концу файла.
Но почему же X сервер жалуется на каталог (раздел) tmp, если место закончилось в var?
Дело в работе механизма мандатного разграничения доступа — в целях изоляции каталогов /tmp разных мандатных уровней они размещаются в /var/private/tmp/, а в момент входа пользователя в систему под мандатными уровнем выше 0 — просто подменяют /tmp. Простое и очень элегантное решение.
Мораль истории такова — своевременно меняйте жёсткие диски и не спешите сносить операционную систему, а то так коней не напасёшься 🙂
Всех благ и до новых встреч.