Управляющие процессы, запущенные Bash Daemon - PullRequest
0 голосов
/ 27 января 2010

В bash я создал простой демон для выполнения команд при изменении моего интернет-соединения:

#!/bin/bash

doService(){
    while
    do  
    checkTheInternetConnection
    sleep 15
    done
}

checkTheInternetConnection(){
    if unchanged since last check
        return
    else
        execute someCommand
    fi
}

someCommand(){
    do something
}

doService

И это сработало очень хорошо для того, что мне нужно для этого.

Единственная проблема заключается в том, что в составе моих команд someCommand и checkTheInternetConnection используются другие встроенные утилиты, такие как arp, awk, grep, head и т. Д.

Однако в 99% случаев мне просто понадобится arp.

Первый вопрос: Необходимо ли оставлять остальные команды открытыми? Есть ли способ убить команду, когда я уже обработал ее вывод?


Другой вопрос: (ПЕРЕМЕЩЕНО В НОВУЮ ПОЧТУ) Я чертовски долго пытался написать функцию «убить все остальные процессы-демоны». Я не хочу, чтобы одновременно работал более одного демона. Какие-либо предложения? Вот что у меня есть:

otherprocess=`ps ux | awk '/BashScriptName/ && !/awk/ {print $2}'| grep -Ev $$`

    WriteLogLine "Checking for running daemons."

    if [ "$otherprocess" != "" ]; then 
        WriteLogLine "There are other daemons running, killing all others."
        VAR=`echo "$otherprocess" |grep -Ev $$| sed 's/^/kill /'`
        `$VAR`
    else
        WriteLogLine "There are no daemons running."    
    fi

Ответы [ 2 ]

0 голосов
/ 27 января 2010

Не могли бы вы подробнее рассказать о первом вопросе? Я думаю, что вы спрашиваете о запуске многих команд по конвейеру (cat xxx | grep yyy | tail -zzz).

Каждая команда будет работать до тех пор, пока в ее канале не будут данные (не достигнутые EOF). Так что в этом примере grep будет выходить только после того, как cat обработает все входные данные и закроет свой конец канала. Но здесь есть хитрость, cat закроет свой конец канала только в том случае, если grep уже прочитал все (по крайней мере, буферизованные) входные данные, потому что вызов записи в каналах блокируется. Так что вы должны иметь это в виду при разработке ваших сценариев.

Но я не думаю, что вам стоит беспокоиться о встроенных утилитах. Как правило, они занимают мало памяти, если это проблема.

0 голосов
/ 27 января 2010

За ваш первый вопрос. Я не совсем понимаю это, но вижу, что вы спрашиваете об одном из двух.

  1. Вы запускаете вещи в функции bash (grep, awk, sed и т. Д.), И поскольку эта функция долго работает, вы боитесь, что используемые вами утилиты так или иначе остаются открытыми.
  2. Вы передаете выходные данные от одной команды к другой и боитесь, что команда останется открытой после ее завершения.

Ни 1, ни 2 не оставят служебные команды «открытыми» после завершения работы. Вы можете доказать это, введя

ps -ef | grep "command" | grep -v 'grep'

по всему коду, чтобы увидеть, что работает под этим именем. или

ps -ef | grep "$$" | grep -v 'grep'

, в котором будут перечислены вещи, которые породил текущий процесс.

UPDATE:

Итак, похоже, вас интересует, как все работает из трубы. Вы можете увидеть это визуально, используя следующую команду:

$ ls / | grep bin | grep bin | ps -ef | grep ls
$

Сравните это с чем-то вроде:

$ find ~ | grep bin | ps -ef | grep find
$

Обратите внимание на то, что 'ls' больше нет в списке процессов, но находка есть. Возможно, вам придется добавить больше команд "grep bin" в конвейер, чтобы получить эффект. Как только первая команда закончит вывод, она закроется, даже если остальные команды еще не завершены. Другие команды будут завершены, когда они завершат обработку выходных данных первой (таким образом, характер канала)

...