Динамическое вычисление значения переменной

[nerve]

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

Shell

$ cat test.sh #!/bin/sh D=`date` echo $D sleep 5 echo $D $ ./test.sh Mon Jul 27 10:56:53 EEST 2015 Mon Jul 27 10:56:53 EEST 2015

[Bizdelnick]

Что Вы подразумеваете под «переменной, которая проверяет ПИД»?

[s.xbatob]

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

А насчёт pid я, сказать честно, ваши намерения совсем не понял. И сигнал вы выбрали неподходящий.

[nerve]

Код: Выделить всё

#!/bin/sh
STOP=`\etc\init.d\service stop`
PID=`ps aux | grep java | grep service | awk '{print $2}'`

backup () {
mysqldump -ususer -p'pass' > $NAME
}

if [ -z $PID ]
  then
    backup
  else
    $STOP
    sleep 15
    if [-z $PID]
      then
    backup
      else
    echo "Something wrong. Unable to stop service"
    fi
fi

[Bizdelnick]

Команда извлечения PID'а у Вас крайне сомнительная. Тем более что если речь о системном сервисе, его PID должен храниться в pid-файле, откуда его лучше всего и взять. При этом надо проверить, что команда, соответствующая этому PID, действительно та, которой запускается сервис, потому что он мог тихо умереть, а его PID получить другой процесс.
А первоначальный вопрос я так и не понял. PID процесса не меняется. Если хотите повторно использовать сохранённое в переменной значение — используйте, только, возможно, надо будет повторить проверку команды запуска процесса.
Отправки сигналов вообще не вижу. Причём они тут?

[s.xbatob]

Код: Выделить всё

PID=`ps aux | grep java | grep service | awk '{print $2}'`
[ "$PID" ] || {
# его и не было
}

....

if kill -0 "$PID"
then
# процесс жив
else
# умер
fi

Всё равно достаточно через жопу, но с SYSV init лучше особо и не сделать. Изучайте systemd :-)

Кстати, а зачем для бекапирования БД вообще что-либо останавливать?

[nerve]

Shell

$ cat test.sh #!/bin/sh echo "123" > test.file PID=`cat test.file` echo $PID echo "456" > test.file echo $PID $ ./test.sh 123 123 $ cat test.file 456

может я не правильно выражаюсь?
вместо второй раз "123" я ожидаю получить "456"
если переменная для этого не подходит, тогда что нужно использовать?

[Bizdelnick]

с SYSV init лучше особо и не сделать. Изучайте systemd

А почему Вы думаете, что там sysvinit?

ОС: OpenBSD

зачем для бекапирования БД вообще что-либо останавливать?

Присоединяюсь к вопросу.

[nerve]

зачем для бекапирования БД вообще что-либо останавливать?

Присоединяюсь к вопросу.

To avoid any data inconsistency and corruption, it is recommended to shut down Confluence before creating a database backup or dump.
проверить что сервис работает или не работает, остановить, проверить что остановился, сделать бекап, запустить.

А почему Вы думаете, что там sysvinit?

ОС: OpenBSD

CentOS 6.3

[Bizdelnick]

To avoid any data inconsistency and corruption, it is recommended to shut down Confluence before creating a database backup or dump.

Ну так это рекомендация для сферической СУБД в вакууме. Почему бы вместо остановки сервиса не залочить таблицы?

[nerve]

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

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

спасибо, видимо это то, в чем я хотел разобраться.

Shell

$ cat test.sh #!/bin/sh pid () { cat test.file } echo "123" > test.file pid echo "456" > test.file pid $ ./test.sh 123 456

[Bizdelnick]

Процесс не должен валиться не то что при локе таблиц, а и при потере связи с СУБД. Если не хочется лочить — есть опция --single-transaction. А можно с реплики бекап делать... Вообще для «горячего» бекапа БД столько всего напридумывали, что ей-ей крайне странно останавливать ради этого какой-то сервис (да ещё и жабописаный, который потом, небось, полчаса стартует).

[s.xbatob]

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

это одна из прямых обязанностей СУБД - разрешать подобные конфликты, так что ничего не развалится. Если, конечно, делать бекап штатными средствами, а не с помощью dd, так любимого многими.