"Уборка мусора" (продолжение)

С почтовым клиентом Evolition дела обстоят несколько сложнее, так как кроме уже известного демона gconfd-1, он использует также oafd. Чтобы разобраться к какому пакету принадлежит эта программа, воспользуемся уже знакомой нам командой:

$ rpm -qf /usr/bin/oafd
oaf-0.6.10-5
$ rpm -qi oaf

Оказывается, OAF – это система активации объектов среды Gnome, которая, в свою очередь, использует ORBit. Понятно, что без нее запустить почтовый клиент не получится. Как и для успешного запуска браузера Galeon, перед повторным использованием почтового клиента Evolution необходимо принудительно завершить процессы, которые с ним связаны. Выполнять завершение процессов в памяти сервера вручную не разумно, целесообразно написать сценарий для демона cron, который, например, ночь, когда никто не работает, будет удалять из памяти все процессы пользователей. Тем самым мы добьемся того, что каждое утро пользователь будет работать с абсолютно свежей средой, лишенной принадлежащих ему аварийно завершенных программ. Ниже представлен пример такого сценария, который я назвал kill_uj.sh:

#!/bin/sh

echo 'Killing all users jobs'

listusers=`ls /home/`
# Цикл по всем пользователям
for username in $listusers
do
    if [ $username != 'lost+found' ]; then
	echo "Work with user: $username"
	# Определение PID процессов пользователя
	jobs=`ps --User=$username -o "pid"| grep -v 'PID'`
	qntt_jobs=0
	# Попытка завершить выполняющиеся процессы
	for jobid in $jobs
	do
	    echo "Terminating job with PID=$jobid"
	    qntt_jobs=`expr $qntt_jobs + 1`
	    `kill $jobid`
	    sleep 1
	done
	# Принудительное завершения оставшихся процессов
	kjobs=`ps --User=$username -o "pid"| grep -v 'PID'`
	for kjobid in $kjobs
	do
	    echo "Killing job with PID=$kjobid"
	    `kill -9 $kjobid`
	    sleep 1
	done
	if [ $qntt_jobs = 0 ]; then
	    echo $'\tNo active jobs'
	else
	    echo $'\t'"Were killed $qntt_jobs jobs"
	fi
    fi
done
echo "Done."

Теперь достаточно настроить автоматический запуск данного сценария каждый день, желательно в ночное время. Например, для запуска его каждый день в 1 час 15 минут следует от имени суперпользователя выполнить такую команду:

# EDITOR=mcedit crontab -e

Далее в появившемся любимом текстовом редакторе Midnight Commander необходимо добавить строку такого вида:

15 1 * * * /home/mikola/Temp/kill_uj.sh > /var/log/kill_uj.log

Сохранить файл и завершить работу с редактором (клавиша F10). Если вы все сделаете правильно, то на экране должна появиться надпись:

crontab: installing new crontab

Переменную окружения EDITOR можно не определять, если вы хорошо умеете работать с текстовым редактором по умолчанию. Например, я с ужасом смотрю на людей которые в своей работе используют vi (vim).

Задача crontab, которую мы создали, будет каждый день в 1:15 выполнять сценарий /home/mikola/Temp/kill_uj.sh, а результат его работы записывать в файл /var/log/kill_uj.log. Так что с утра по содержимому файла /var/log/kill_uj.log можно будет судить, сколько ненужных процессов было завершено.

Правда следует заметить, что используя такой сценарий, мы обязываем пользователей завершать свои программы перед уходом домой. Например, вместе со всеми процессами пользователя будет удалена также программа, скачивающая большой файл из сети Интернет, которую пользователь хотел оставить включенной всю ночь. Также автоматический запуск такого сценария может нарушить расписание пользовательских заданий crontab. Правда, я очень сомневаюсь, что ваши пользователи будут использовать crontab, да и к тому же всегда можно договориться, чтобы они запускали свои задания в другое время, например, с 21 до 23 часов.

Систему сбора "мусора" можно настроить также и на инспектирование процессов, запущенных и от имени суперпользователя root, а также других вспомогательных пользователей таких как: nobody, apache, gdm и т.д. Но следует заметить, что с подобными процессами проблем обычно всегда меньше.

Проверять также нужно присутствие двух копий одной и той же программы в памяти сервера, которые запущены от имени одного пользователя. Иногда это может указывать на аномальное поведение программы. Ниже приводится пример команды, которая помогает отследить такие процессы:

$ ps -ax -o "user comm pid" | grep -v root | sort | uniq -d -w 26
apache   httpd            32473
mikola   bash             16033
mikola   kdeinit          11088
mikola   less             16716
mikola   man              16705
mikola   sh               16708
mikola   xterm            16031
nata     kdeinit           8927
ula      kdeinit          11014

Как видно по результату ее работы, ничего подозрительного в системе нет, так как для процессов httpd, bash, kdeinit, less, man, sh, xterm и kdeinit наличие нескольких копий в памяти считается вполне нормальным. Для уменьшения количества результатов были проигнорированы процессы, запущенные от имени супер-пользователя root (grep -v root).

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

В главе, посвященной советам по настройке прикладных программ для Х-терминалов, упоминалось о проблеме открытия и печати файлов в пакете OpenOffice. Причина скрывалась в разрастании файла ~/.openoffice/user/psprint/pspfontcache в домашнем каталоге пользователя. Давайте напишем сценарий для сервиса crontab, который будет автоматически удалять файлы pspfontcache при достижении ими больших размеров. Используя уже имеющиеся в нашем распоряжении наработки, получим такое содержимое этого сценария (файл kill_pscache.sh):

#!/bin/sh

echo 'Removing pspfontcache file for all users'

listusers=`ls /home/`
# Цикл по всем пользователям
for username in $listusers
do
    if [ $username != 'lost+found' ]; then
	echo "Work with user: $username"
	# Определение существования большого файла pspfontcache
	filepscache='/home/'$username'/.openoffice/user/psprint/pspfontcache'
	ksize=200 # минимальный размер файла в Кбайтах
	if [ -f $filepscache ]; then
	    echo 'File exists'
	    fsize=`find $filepscache -size +${ksize}k`
	    if [ -z $fsize ]; then
		echo "But file too small"
	    else
		echo 'Removing '$fsize
		`rm -f $fsize`
	    fi
	else
	    echo 'There is no file'
	fi
    fi
done
echo "Done."

Данный сценарий ищет файлы ~/.openoffice/user/psprint/pspfontcache размером более 200 Кбайт и удаляет их. После создания этого файла давайте добавим его в список задач утилиты crontab, например, для запуска во вторник и пятницу каждую неделю. Для этого выполним команду:

# crontab -e

В текстовом редакторе добавим строку, содержащую такие данные:

25 2 * * 2,5 /home/mikola/Temp/kill_pscache.sh > /var/log/kill_pscache .log

После сохранения файла расписания crontab, оптимизации запуска и открытия файлов OpenOffice, будет автоматически выполняться в 2:25 ночи каждую неделю по вторникам и пятницам.

Практически все современные дистрибутивы операционной системы Linux умеют выполнять ротацию системных журналов. Более того, чтобы упростить жизнь пользователям, они делают это по умолчанию сразу после установки операционной системы, так что настраивать практически ничего не нужно. Если же вас не устраивают установки ротации в вашей системе, то можете смело менять параметры файла конфигурации /etc/logrotate.conf и, конечно, файлы для ротации конкретных служб непосредственно из каталога /etc/logrotate.d/.

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

Пока интересно, читаем дальше!