синхронно ожидать завершения очистки rsyslog - PullRequest
0 голосов
/ 30 января 2019

Я запускаю rsyslogd 8.24.0 с локальным лог-файлом.

У меня есть тест, который запускает программу, которая делает некоторые записи в системном журнале (записи из моего теста переходят в другой файл через настройку rsyslog.conf)затем возвращается к сценарию оболочки, чтобы проверить наличие в журнале ожидаемого содержимого.Это обычно работает, но иногда терпит неудачу, как будто регистрация не произошла.Я добавил сброс (используя сигнал HUP) в сценарий оболочки, прежде чем он выполнит проверку.Я вижу, что произошел HUP и что в журнале есть правильная запись, но проверка скрипта все равно не удалась.Есть ли способ для сценария оболочки ожидать завершения сброса?Я могу добавить произвольный сон, но предпочел бы иметь что-то более определенное.

Вот соответствующие биты сценария оболочки:

# Set syslog to send dump_hook's logging to a local logfile...
sudo echo "user.*   `pwd`/dump_hook_log" >> /etc/rsyslog.conf
sudo systemctl restart rsyslog.service
echo "" > ./dump_hook_log

# run the test program which does syslog logging

kill -HUP `cat /var/run/syslogd.pid` # flush syslog 
if [ $? -ne 0 ]
then 
    logFail "failed to HUP `cat /var/run/syslogd.pid`: $?"
fi
echo "sent HUP to `cat /var/run/syslogd.pid`" 
grep <the string I want> ./dump_hook_log >/dev/null

Строка, о которой идет речь, всегда находится в dump_hook_logвремя, когда тест сообщил о неудаче, и я пошел посмотреть на него.Я предполагаю, что это должно быть, что очистка не завершена ко времени grep.

Вот пример: In / var / log / messages

2019-01-30T12:13:27.216523+00:00 apx-ont-1 apx_dump_hook[28279]: Failed to open raw dump file "core" (Is a directory)
2019-01-30T12:13:27.216754+00:00 apx-ont-1 rsyslogd: [origin software="rsyslogd" swVersion="8.24.0" x-pid="28185" x-info="http://www.rsyslog.com"] rsyslogd was HUPed

Мод датыфайл журнала (примечание: это раньше, чем содержащиеся в нем записи!):

rw-rw-rw- 1 nealec appexenv1_group 2205 2019-01-30 12:13:27.215053296 +0000 testdir_OPT/dump_hook_log

Последняя строка файла журнала (здесь только записи apx_dump_hook):

2019-01-30T12:13:27.216523+00:00 apx-ont-1 apx_dump_hook[28279]: Failed to open raw dump file "core" (Is a directory)

Ошибка сообщения скрипта:

Wed 30 Jan 12:13:27 GMT 2019 PSE Test 0.2b FAILED: 'Failed to open raw dump file' not found in ./dump_hook_log

Ответы [ 2 ]

0 голосов
/ 31 января 2019

Мне кажется, я понимаю это сейчас.HUP заставляет rsyslogd закрыть свои открытые файлы, но не открывает файл до тех пор, пока ему не понадобится войти в него.Рассмотрим следующее: я использую inotify для ожидания закрытия файла, например:

case 9:
    {
        // Wait for the file, specified in argv[2], to be closed
        int inotfd = inotify_init();           
        if (inotfd < 0) {
            printf("inotify_init failed; errno %d: %s\n",
                errno, strerror(errno));
            exit(99);
        }
        int watch_desc = inotify_add_watch(inotfd, argv[2], IN_CLOSE);
        if (watch_desc < 0) {
            printf("can't watch %s failed; errno %d: %s\n",
                argv[2], errno, strerror(errno));
            exit(99);
        }
        size_t bufsiz = sizeof(struct inotify_event) + PATH_MAX + 1;
        struct inotify_event* event = static_cast<inotify_event*>(malloc(bufsiz));
        if (!event) {
            printf("Failed to malloc event buffer; errno %d: %s\n",
                errno, strerror(errno));
            exit(99);
        }

        /* wait for an event to occur with blocking read*/
        read(inotfd, event, bufsiz);
    }

Затем в моем сценарии оболочки я жду этого:

# Start a process that waits for the log file be closed
${bin}/test_dump_hook.exe 9 "./dump_hook_log" &  
wait_pid=$!

# Signal syslogd to cause it it close/reopen its log files
kill -HUP `cat /var/run/syslogd.pid` # flush syslog 
if [ $? -ne 0 ]
then 
    logFail "failed to HUP `cat /var/run/syslogd.pid`: $?"
fi
wait $waid_pid

Я не нахожу этого никогдавозвращается.Отправка HUP в rsyslogd из другого процесса также не прерывает его ожидания, но это делает кошка (которая открывает / закрывает файл) файла журнала.

Это потому, что HUP в оболочкеСценарий был выполнен до того, как другой процесс ожидал его.Таким образом, файл был уже закрыт в начале ожидания, и поскольку больше не ведется запись в этот файл, он не открывается снова и не нуждается в закрытии при получении любых последующих HUP, поэтому событие никогда не завершается в ожидании..

Поняв это поведение, как я могу быть уверен, что журнал был записан до того, как я его проверил?Я пошел с этим решением;поместите известное сообщение в журнал и подождите, пока оно не появится, я знаю, что записи, которые я жду, должны быть до этого.Как это: -

function flushSyslog
{
    logger -p user.info -t dump_hoook_test "flushSyslog"
    # Signal syslogd to cause it it close its log file
    kill -HUP `cat /var/run/syslogd.pid` # flush syslog 
    if [ $? -ne 0 ]
    then 
        logFail "failed to HUP `cat /var/run/syslogd.pid`: $?"
    fi
    # wait upto 10 secs for the entry we've just logged to appear
    sleeps=0 
    until     
        grep "flushSyslog" ./dump_hook_log > /dev/null 
    do  
        sleeps=$((sleeps+1))
        if [ $sleeps -gt 100 ]
        then
            logFail "failed to flush syslog dump_hook_log"
        fi
        sleep 0.1
    done        
}
0 голосов
/ 30 января 2019

Это кажется немного тяжелым решением, но вы можете использовать системный inotify api, чтобы дождаться закрытия файла журнала (результат сигнала HUP).Например,

inotifywait -e close ./dump_hook_log

будет зависать до тех пор, пока rsyslogd (или любой другой процесс) не закроет файл, когда вы получите сообщение

./dump_hook_log CLOSE_WRITE,CLOSE 

и программа завершит работу с кодом возврата0. Вы можете добавить тайм-аут.

...