Погадал, но так и не понял что такое "окно улетает"....

Зато знаю более удобный способ добавить настройки Информикс без ужаса for/cat/grep

Всем настройкам в ids_env добавтье export. В настройки же уберите и изменение PATH.

Далее просто создайте ссылку на ваши настройки /opt/informix/ids_env в /etc/profile.d

ln -s /opt/informix/ids_env в /etc/profile.d/informix.sh


Это будет автоматически добавлять ваши настройки всем при входе в систему (точнее при создании сессии).

Если всем не надо, то опять таки есть более прямой путь.

Напишите в .bash_profile вот так
(только тогда права на исполнение добавьте сhmod a+x /opt/informix/ids_env)

. /opt/informix/ids_env


И почитайте man bash

Это всё не рашает вопроса нескольких экземпляров в системе, но позволяет конфиг какого-то одного прописывать по уолчанию.

Переключать на ходу между экземплярами можно создав каждому свой ids_env и выполнять последний вариант "точка конфиг" прямо в командной строке.

При нескольких экземплярах (да и про одном тоже) полезно прописать в PS1 вывод текущего имени сервера.

Добавьте в .bash_profile

export PS1='\h[$INFORMIXSERVER]:\w>'


Предупреждение: Технически файл настроек будет при включении исполняться как обычный скрипт баша. Это отличает мой вариант от вашего for/cat/grep.

С "улетающи окном" я по прежнему не дружу. По описанию похоже что у вас срабатывает сразу exit в .bash_profile или .bashrc.

Но меня настараживает вопрос про "символическую ссылку" в /etc/init.d. Вы что, в .bashrc включаете скрипт запуска Информикса ???

Надеюсь я ошибаюсь.

По буквам env в названии ids_env я решил что это файл только с настройками и исходя из этого ругался словами "ужас" и давал советы. Если же это и скрипт запуска информикс, то срочно отделяем настройки от скрипта !

Я приведу два файла из своей рабочей системы:

- файл с настройками - пусть он у вас будет ids_env

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

Файл настроек .

Замените XXXX чем надо.

export INFORMIXDIR=/opt/informix
export INFORMIXSERVER= XXXX
export ONCONFIG=onconfig.$INFORMIXSERVER
export DB_LOCALE= XXXX
export CLIENT_LOCALE= XXXX
export DBDATE="Y4MD-"

export INFORMIXSQLHOSTS=$INFORMIXDIR/etc/sqlhosts

#export PDQPRIORITY=off

PATH=$PATH:$INFORMIXDIR/bin


Скрипт управления .

Он старый. Не правильный с точки зрения скриптов автозапуска. Но работает.

Скрипт при использовании с командной строки может запускать-останавливать разные экзепляры информикса.

По умолчанию - тот что описан в ids_env

Для запуска/остановки руками просто
/opt/informix/informix.rcd start
/opt/informix/informix.rcd stop


При использовании как
/opt/informix/informix.rcd start xxx
/opt/informix/informix.rcd stop xxx


работает с тем экземпляром, который описан в ids_env.xxx

Скрипт от CentOS 5. Может у вас в Suse сразу не заработать, но его легко допилить.

Положите файл рядом с ids_env (например /opt/informix/informix.rcd) и дайте прав на выполнение.

Запускайте информикс или при старте системы или руками после входа. Но только не включайте ни в какие .bash* !

Для запуска вместе с системой (применительно к СentOS, для Suse читайте доки). Всё делать root-ом

- создайте ссылку в /etc/init.d
ln -s /opt/informix/informix.rcd /etc/init.d/informix


- cообщите системе что появился новый сервис
chkconfig -add informix


- включите автозапуск при старте системы и автоостановку при выключении
chkconfig informix on

sinka2002Еще небольшой вопрос относительно скрипта. Не поняла функцию строки
echo > /var/run/informix.pid


смело забудьте и сотрите :)

"Настоящие" скрипты автозапуска в /var/run/имясервиса.pid хранят номер процесса демона который запускают.

Типа проверять запущен или нет и предотвращать повторные запуски при уже работающем.

Нам с информиксом это никаким боком не надо - повторно не запустите как не старайтесь.

А "запущенность" мы же знаем как поверить: onstat -

99.5% точности на самом деле. Видел случаи когда информикс умер, а разделяемая память осталась и onstat врало.

Будете в реальной системе делать мониторинг - только регулярые попытки соеденить и провести хотя бы пустую транзакцию.

Достаточно одного по моей практике.

Я предлагах .bash_profile (а не .profile) если вся эта возня с настройка не нужна каждому пользователю.

Если нужна всем - то симлинк в /etc/profile.d

Проверьте, что /etc/profile.d у вас вообще в игре - гугл в руки и искать работает ли оно в вашей Suse и если нет, то что взамен - у меня CentOS - это немного разные системы

Проверьте, что логин который проверяете имеет шел /bin/bash, а не какой-то другой.

Ну и man bash :)