Сервисное состояние Соляриса и зависимости
В модели Unix, запуская другую программу включает два primivites:
fork()создает (почти) идентичную копию обработки вызовов. Новый процесс называют дочерним процессом, и исходный процесс называют родительским процессом. Дочерний процесс выполняет тот же код как оригинал, имеет те же полномочия, имеет ту же среду и получает копию изменяемой памяти данных родительского процесса. Самое видимое различие между двумя процессами - то, что у них есть различные идентификаторы процесса, и различные идентификаторы родительского процесса (PPID ребенка является PID родителя).execve()заменяет код и данные текущего процесса кодом и данные, загруженные из исполняемого файла. Этот системный вызов берет новую среду процесса как аргумент.
Большинство высокоуровневых функций, созданных вокруг fork() и execve() передайте текущую среду процесса execve(). Таким образом, если процесс не изменяет свою собственную среду или вызовы execve() непосредственно, названная программа наследует среду программы вызова.
Оболочки обычно передают свою среду программам, которые они называют. Можно изменить среду оболочки в любое время путем присвоения значения переменной среды (foo="some value"; необходимо звонить export foo если переменная уже не находится в среде), или удалите переменную из среды путем сбрасывания ее (unset foo). Если Вы хотите запустить внешнюю программу с переменными различной или новой среды, существует синтаксис ярлыка:
foo="some value" mycommand
примерно эквивалентно
(foo="some value"; export foo; exec mycommand)
(где круглые скобки ограничивают объем установки foo).
Лучше используйте коллектор, спрашивают и настраивают сервис для создания XML-файла для Вас: http://code.google.com/p/manifold/
1 - Определите mysql сервис как сервис зависимости при конфигурировании xml декларации для weblogic сервиса. Таким образом, Ваш weblogic не будет запущен, целый mysql сервис, как сообщают, полностью не онлайн. Это кажется логичным, так как Ваше weblogic приложение зависело бы от mysql сервисной доступности, оно не сделает ненужных попыток к дб connect/sql выполнение оператора, когда mysql сервис дб снизится.
2 - Так как сервис зависимости идет офлайновое/ухудшенное состояние, Ваша weblogic услуга также пойдет офлайн и не будет работать. Таким образом, нет никакого шанса для weblogic сервиса, чтобы попытаться сделать mysql сервис назад онлайн, в то время как он имеет шанс, так как себя входит в режим техобслуживания. Больше, нет никакой гарантии weblogic для инициирования после этого, так как mysql сервис входит в режим обслуживания/в режиме офлайн/ухудшать, smf отметит weblogic сервис, также ухудшенный/в режиме офлайн, и следовательно он не может использоваться для запуска mysql сервиса. Это может быть очевидным случаем циклической зависимости, которая должна быть разрешена, при помощи трети module/cronjob/transient сервис для заботы об этих обоих сервисах.
Теперь, когда ясно, что основной сервис зависимости является mysql для выполнения онлайн почти все время за доступностью и чистым функционированием weblogic, я предложил бы использовать третий модуль / сценарий (даже как cronjob, сделает), который контролировал бы состояния mysql сервиса как предпочтенный приоритет и затем weblogic сервис. Это должно заботиться об обработке/выполнении SMF, заживающие команды упаковывают любой сервис, понижается.