сценарий init.d, не работающий …, но команда, работает, если я выполняю его в консоли
Спасибо за Ваши ответы.
Я буду проверять ответ abigblackman более тщательно позже, в настоящее время я устанавливал Hamachi для нарушения между моей локальной сетью и моими друзьями, таким образом, я могу соединиться легко с SQL-сервером. Это хорошо работает (очень быстро на самом деле).
Еще раз, спасибо за Вашу поддержку. Vondip
попытайтесь добавить
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
к верхней части init сценария.
-
1Justin, почему это необходимо, чтобы быть в сценарии? – massi 8 March 2010 в 01:56
-
2потому что/usr/local/bin/bluepill, вероятно, пытается запустить больше программ, расположенных в/usr/local, который это не может найти./usr/local/bin/bluepill мог бы быть сценарием оболочки, можно попытаться читать его. – Justin 8 March 2010 в 03:55
хорошо.. немой вопрос, но Вы устанавливали сценарий для запуска при начальной загрузке? Я более знаком с дистрибутивами стиля debian, но ntsysv или chkconfig могли бы быть тем, в чем Вы нуждаетесь.
-
1
Я повторю призыв Kamil к выводу, когда выполнено.
Кроме того, имейте Вас попробованный chkconfig --add bluepill и chkconfig bluepill on.
Иначе я держу пари, что это - своего рода переменная среды в сценарии. Попытайтесь получить среду в запуске через . /etc/profile и т.п. Тем более, что это похоже, это установлено в/usr/local/bin. Это, возможно, должно СОЕДИНИТЬ КАНАЛОМ или набор LD_LIBRARY_PATH правильно.
-
1Поскольку я сказал в ответе на Kamil Kisiel' s комментарий, даже после того, как сервер запущен..., когда я пробую сервис bluepill_script, запускаются, это, кажется, работает (никакая ошибка не отображена), но it' s не делающий его задание – massi 6 March 2010 в 05:36
Отсутствие ошибок в журнале не является никаким ясным признаком, что init сценарий работает. Два простых шага отладят это.
- Добавьте некоторые детали отладки в сценарии. Мне нравится писать номер строки в файл журнала от различных точек со сценарием. Никакой вывод? Затем это почти наверняка не выполняется.
- Удостоверьтесь, что сценарию на самом деле позволили работать, когда Вы думаете, что он имеет, как несколько других уже заявили. Если это не выполняется, который мог бы считать из-за отсутствия сообщений об ошибках в журналах.
Я использую следующий init.d сценарий и имел подобную проблему, потому что bluepill драгоценный камень был установлен под rvm установкой. Заметьте необходимость получить любого rvm переменная среды, но то же, возможно, было достигнуто путем определения источника/etc/profile (так как это также устанавливается там). Я использую рецепт поваренной книги Opscode для установки их, таким образом, те пути установлены, чтобы быть переменные данный, где rvm поваренная книга устанавливает свои драгоценные камни.
#!/bin/bash
#
# Bluepill
#
# chkconfig: - 85 15
# description: start, stop, restart bluepill
#
RETVAL=0
if [[ -s /usr/local/rvm/scripts/rvm ]] ; then source /usr/local/rvm/scripts/rvm ; fi
case "$1" in
start)
for i in /etc/bluepill/*.pill; do
/usr/local/rvm/gems/ruby-1.9.2-p180/bin/bluepill load $i
done
RETVAL=$?
;;
stop)
/usr/local/rvm/gems/ruby-1.9.2-p180/bin/bluepill stop
/usr/local/rvm/gems/ruby-1.9.2-p180/bin/bluepill quit
RETVAL=$?
;;
restart)
/usr/local/rvm/gems/ruby-1.9.2-p180/bin/bluepill restart
RETVAL=$?
;;
status)
/usr/local/rvm/gems/ruby-1.9.2-p180/bin/bluepill status
RETVAL=$?
;;
*)
echo "Usage: bluepill {start|stop|restart|status}"
exit 1
;;
esac
exit $RETVAL
вам также может потребоваться поместить ссылку в одну из папок / etc / rcX (в зависимости от предполагаемого уровня запуска) и запустить
sudo run update-rc.d SkriptnameWithinInitDWithoutPath defaults