AIX непрекъснато наблюдение на регистрационни файлове

Имам просто изискване да продължа да наблюдавам лог файл и когато определен термин се появи в него, да изпратя JMS съобщение. Използвах кода (checkScript.sh) по-долу и той работи перфектно до полунощ, когато стартира скрипт за архивиране.

string="requiredstring"
tail -n 0 -f /home/user/log.log | \
while read LINE
do
echo "$LINE" | grep -q $string
java tibjmsProducer -server tcp://localhost:7222 -user admin -password admin -queue test.queue "$LINE"
done

В полунощ има скрипт за архивиране, който стартира и преименува файла log.log на log.log.1 и докосва полето log.log. Така че ще завършим с два файла log.log и log.log.1. Тъй като AIX не може да следи тези файлови промени с помощта на tail, тъй като опашката в AIX продължава да проследява само файловия дескриптор, аз написах друг скрипт, който ще рестартира горния код след завършване на архивирането.

kill -9 `ps -ef|grep "tail -n 0 -f" | grep "checkScript"| awk '{print $2}'`
echo "Killed process. Restarting the shell script"
./checkScript.sh >> /home/user/Service.log 2>&1 &

Интересното е, че работи точно по предназначение. Но след рестартиране, регистрационният файл спира да се наблюдава и не се задействат събития, но ps -ef в скрипта показва, че checkScript работи, изпълнявайки опашката.

Правя ли нещо грешно тук?

Благодаря!


logging monitoring continuous aix tail
person aadi    schedule 30.11.2014    source източник

Отговори (2)


arrow_upward
1
arrow_downward

Вместо сляпо преименуване, предлагам ви cp и след това cat /dev/null (което ще запази същия inode и ще позволи на вашия оригинален процес да продължи без прекъсване). Освен това предлагам да използвате командата date. Нещо като

#!/bin/sh
DT=`date "+%Y%m%d%H%M%S"`
LF="/home/user/log.log"
FN="$LF-$DT"
cp "$LF" "$FN"
cat /dev/null > "$LF"

И накрая, можете да помислите за добавяне (ако приемем, че имате bzip2)

bzip2 -9 "$FN"
person Elliott Frisch    schedule 30.11.2014
comment
Съжалявам за объркването, Елиът. Те правят абсолютно същото, копират всички файлове и след това gzip+tar папката с всички големи регистрационни файлове. За да се противопоставя на този проблем, написах скрипт за рестартиране на моя checkScript файл и поставянето му в crontab. Но интересното е, че не работи според очакванията, когато се стартира от cron, но работи добре, когато стартирам ръчно сутрин (загуба на 8 часа транзакции) - person aadi; 30.11.2014
comment
@aadi Ако последната стъпка е cat /dev/null > $LF (вместо rm), тогава не е необходимо да рестартирате монитора си. Файловият дескриптор ще остане постоянен, но съществуващото файлово съдържание ще бъде премахнато. - person Elliott Frisch; 30.11.2014
comment
Благодаря Елиът. Използват > filename.log за нулиране на файла. Мисля, че това е еквивалентно на използването на това, което сте предложили. Ще проверя и ще се свържа с вас. - person aadi; 30.11.2014

arrow_upward
1
arrow_downward

ха! Най-накрая един прост (правилен) Google даде решение на този глупав проблем. Това, което забравих да спомена е (мислейки си, че няма значение), моят скрипт се рестартира от crontab. И cron работи с различен набор от променливи на средата, който не включва Java директория. Следователно, докато скриптът работи, той не изпраща резултатите към JMS сървъра.

За да коригирам този проблем, промених скрипта за рестартиране, както е показано по-долу, и той работи като чар!

. ${HOME}/.profile
kill -9 `ps -ef|grep "tail -n 0 -f" | grep "checkScript"| awk '{print $2}'`
echo "Killed process. Restarting the shell script"
./checkScript.sh >> /home/user/Service.log 2>&1 &

Това зареди всички правилни и необходими пътища за мен и скриптът работи добре сега. Командата . ${HOME}/.profile помогна за разрешаването на зависимостите в скрипта и отсега нататък ще я използвам за всички crontab скриптове, които ще напиша. Благодаря ти!

person aadi    schedule 01.12.2014
comment
голям плюс за решаване на вашия собствен crontab проблем! Късмет. - person shellter; 05.01.2015