Приветствую!

Поставлена задача запустить сервер под Linux. Не получается, блин. Я в unix не силён, к сожалению. Может ткните, кто знает. Даю сопутствующую информацию.

uname -a
Linux persey.dati.lv 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64 x86_64 x86_64 GNU/Linux

oninit -v
Checking group membership to determine server run modesucceeded
Reading configuration file '/opt/informix/etc/onconfig'...succeeded
Creating /INFORMIXTMP/.infxdirs ... FAILED
Creating infos file "/opt/informix/etc/.infos.ol_persey" ... "/opt/informix/etc/.conf.ol_persey" ... succeeded
Writing to infos file ... succeeded
Checking config parameters...succeeded
Allocating and attaching to shared memory...FAILED
oninit: Fatal error in shared memory creation

IDS 7.31.UD8 online.log
16:43:00 shmget: [EEXIST][17]: key 52564801: shared memory already exists
16:43:00 mt_shm_init: can't create resident segment

SHMBASE я по-всякому пытался ставить: и 0x10000000L как в "MACHINE SPECIFIC NOTES", и 0x44000000L как в onconfig.std, и просто с потолка что-то - результат один.

> Смотреть надо на строку
> Creating /INFORMIXTMP/.infxdirs ... FAILED
Создал директорию вручную, теперь oninit -v выглядит чуть по-другому:

Checking group membership to determine server run modesucceeded
Reading configuration file '/opt/informix/etc/onconfig'...succeeded
Creating /INFORMIXTMP/.infxdirs ... succeeded
Creating infos file "/opt/informix/etc/.infos.ol_persey" ... "/opt/informix/etc/
.conf.ol_persey" ... succeeded
Writing to infos file ... succeeded
Checking config parameters...succeeded
Allocating and attaching to shared memory...FAILED
oninit: Fatal error in shared memory creation

Но в online.log без изменений:

14:57:46 shmget: [EEXIST][17]: key 52564801: shared memory already exists
14:57:46 mt_shm_init: can't create resident segment

> Похоже, при инсталляции поломались permissions.
Вот это я тоже не очень понимаю, почему, с какой стати должно что-то ломаться?

Ещё идеи будут?

Спасибо отозвавшися - перезагрузка помогла, однако... Но появилась следующая проблема:

10:11:19 Error building 'sysmaster' database.
10:11:19 See '/tmp/buildsmi.2656'.

В самом этом файле:

dbaccess: error while loading shared libraries: libncurses.so.4: cannot open shared object file: No such file or directory


Чего теперь делать?

> У тебя все очень-очень оригинально:
> 2.4.21-4.ELsmp x86_64 x86_64 x86_64 GNU/Linux
Очень может быть... Но для меня, если честно, эта строчка - просто набор символов. Так что всё это означает?

> Информикс какой версии?
7.31.UD8
У меня, кстати, было подозрение, что 32-битный IDS на 64-битном OS вообще работать не будет. Опровергните или подтвердите, если кто знает.

> Покажи ls -l /usr/lib/libncurses*
lrwxrwxrwx 1 root root 15 Jan 31 08:34 /usr/lib/libncurses.so -> libncurses.so.5
lrwxrwxrwx 1 root root 26 Feb 7 11:56 /usr/lib/libncurses.so.4 -> /usr/lib/libncurses.so.5.3
lrwxrwxrwx 1 root root 17 Jan 31 08:34 /usr/lib/libncurses.so.5 -> libncurses.so.5.3
-rwxr-xr-x 1 root root 866468 Sep 21 2003 /usr/lib/libncurses.so.5.3
lrwxrwxrwx 1 root root 16 Jan 31 08:34 /usr/lib/libncursesw.so-> libncursesw.so.5
lrwxrwxrwx 1 root root 18 Jan 31 08:34 /usr/lib/libncursesw.so.5 -> libncursesw.so.5.3
-rwxr-xr-x 1 root root 983035 Sep 21 2003 /usr/lib/libncursesw.so.5.3

И какие из этого можно сделать выводы?

Я так понял, мне кто-то уже переназначил библиотеки (некий root). Ну и ладно. Короче - сервер работает, и даже dbaccessом можно запрос выполнить. Теперь бы мне с клиентской машины приконнектиться... Расскажите в двух словах про /etc/hosts, про /etc/services, про firewall... Под Виндами всё это как-то автоматом происходит - не припомню, чтобы париться приходилось когда-нибудь...

> В виндах тоже есть services
Есть. Но инсталляция сервера сама туда вписывает строчку. По умолчанию:
turbo 1526/tcp #ol_servername
Это-то ладно - туда-то я вписал...

> hosts
Тоже есть. Но туда как-то не пиходилось мне ничего писать. Есть там одна строчка:
127.0.0.1 localhost
и вроде как больше ничего не нужно... Более того я даже пытался (ну там, на Linuxе) вписать:
194.8.32.55 persey.dati.lv persey
(прошу учесть, с помощью vi через telnet :-), так он, блин (файл), read only - и как дальше быть? Нашёлся добрый человек - вписал (правда, никому не сказал, как, секретник такой :-) Но что он делал с firewallом (и делал ли вообще) - осталось тайной за 7-ю печатями.

> (%WINDIR%\SYSTEM32\DRIVERS\ETC\)
Да-да, я знаю, где он находится. Я там даже hosts.equiv создавал неоднократно...

> Другое дело, что есть windows-way ("оно как-то заработало и как-то
> работает. Не дышать")
О-о... Это что ещё за наезды? Мы тоже - не луком сыты :-)

> и unix-way, когда всё приходится делать руками.
Так я уже согласен... Хотя и не слишком всё это удобно....

> Информиксовый сервер умеет, может и любит
Не верю! Пограмма не может любить. В программе может быть что-то реализовано - так верю.

> слушать сетевой сокет на протоколе tcp.
Ну, это вообще сленг какой-то... Что значит слушать? Я как-то (давно) писал на ассемблере программку под модем, вот там я примерно представляю, что значит слушать - проверять в цикле значения регистров и ячеек памяти... А что такое сокет, объясните на пальцах? С протоколом вроде ясно - некая договорённость о формате данных...

> sqlhosts, setnet
Про это я тоже в курсе.

Короче. Всё заработало. Но. Как-то не всё мне опять понятно. А именно. В online.log при старте появляются строки:

11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x10000000, size=330489856
11:30:05 Segment locked: addr=0x23b2e000, size=262144000
11:30:05 Segment locked: addr=0x23b2e000, size=262144000
11:30:05 Segment locked: addr=0x23b2e000, size=262144000
11:30:05 Segment locked: addr=0x23b2e000, size=262144000
11:30:05 Segment locked: addr=0x23b2e000, size=262144000
11:30:05 Segment locked: addr=0x23b2e000, size=262144000
11:30:05 Segment locked: addr=0x23b2e000, size=262144000
11:30:05 Segment locked: addr=0x23b2e000, size=262144000

Это вообще как понимать? Действительно по одному адресу и одного размера так много раз? Зачем? На виндах по-другому - 1 резидентный и 1 виртуальный, ничего лишнего. Подскажите сразу, как в этом можно убедиться командами OS, а то -g seg показывает всё красиво:

IBM Informix Dynamic Server Version 7.31.UD8 -- On-Line -- Up 03:47:47 -- 578744 Kbytes
Segment Summary:
id key addr size ovhd class blkused blkfree
1736706 1381386241 10000000 330489856 24784 R* 40337 6
2064396 1381386251 23b2e000 262144000 4644 V* 931 31069
Total: - - 592633856 - - 41268 31075
(* segment locked in memory)

А вот ipcs:

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x52564801 3145730 root 660 33554432 12 locked
0x52564802 3178499 root 660 33554432 12 locked
0x52564803 3211268 root 660 33554432 12 locked
0x52564804 3244037 root 660 33554432 12 locked
0x52564805 3276806 root 660 33554432 12 locked
0x52564806 3309575 root 660 33554432 12 locked
0x52564807 3342344 root 660 33554432 12 locked
0x52564808 3375113 root 660 33554432 12 locked
0x52564809 3407882 root 660 33554432 12 locked
0x5256480a 3440651 root 660 28499968 12 locked
0x5256480b 3473420 root 660 33554432 12 locked
0x5256480c 3506189 root 660 33554432 12 locked
0x5256480d 3538958 root 660 33554432 12 locked
0x5256480e 3571727 root 660 33554432 12 locked
0x5256480f 3604496 root 660 33554432 12 locked
0x52564810 3637265 root 660 33554432 12 locked
0x52564811 3670034 root 660 33554432 12 locked
0x52564812 3702803 root 660 27262976 12 locked
------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 131072 root 660 9
0x00000000 163841 root 660 1
0x00000000 196610 root 660 1
0x00000000 229379 root 660 1

Разъясните, кто понимает?

И последнее. На сервере 6 Гб оперативки, я пытался выделить Informixу 2. Не получается. Чуть больше буферов или чуть больше виртуальный сегмент - получаю:

15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 Segment locked: addr=0x10000000, size=606519296
15:21:55 shmat: [EINVAL][22]: shared memory base address illegal
15:21:55 Contiguous shared memory segment allocation failed at 0x3e26c000.
Allocation retried at 0x0.
Check SHMBASE is consistent with the value in $INFORMIXDIR/etc/onconfig.std.
Consider using a different SHMBASE value in your ONCONFIG file.
If shared memory segments are not allocated in increasing address order,
memory block allocation performance may degrade.
15:21:55 mt_shm_init: can't create virtual segment

Ну и ipcs соответственно:

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x52564802 2359299 root 660 33554432 0 locked
0x52564803 2392068 root 660 33554432 0 locked
0x52564804 2424837 root 660 33554432 0 locked
0x52564805 2457606 root 660 33554432 0 locked
0x52564806 2490375 root 660 33554432 0 locked
0x52564807 2523144 root 660 33554432 0 locked
0x52564808 2555913 root 660 33554432 0 locked
0x52564809 2588682 root 660 33554432 0 locked
0x5256480a 2621451 root 660 33554432 0 locked
0x5256480b 2654220 root 660 33554432 0 locked
0x5256480c 2686989 root 660 33554432 0 locked
0x5256480d 2719758 root 660 33554432 0 locked
0x5256480e 2752527 root 660 33554432 0 locked
0x5256480f 2785296 root 660 33554432 0 locked
0x52564810 2818065 root 660 33554432 0 locked
0x52564811 2850834 root 660 33554432 0 locked
0x52564812 2883603 root 660 33554432 0 locked
0x52564813 2916372 root 660 2539520 0 locked

Что делать?

> Если бы ты еще сказал, что у тебя подразумевается под клиентом ? ....
Я подумал, что это неважно - с любой другой машины.

> Если под Винь, то настраивается точно так же
Так я вроде всё так и сделал, а он мне - 908. Очень информативно...

P.S. Я пока так и не понял, на сервере в /etc/hosts надо что-то писать или нет? Зачем? И почему на Win - не надо? Почему?

> Запись про lock у меня ровно одна.
Кажется, я знаю почему. RESIDENT 1. Поставь в -1, и принудительно резидентными станут 2 сегмента (и резидентный, и виртуальный).

> Segment Summary:
> id key addr size ovhd class blkused blkfree
> 0 1381386241 50000000 117440512 5972 R* 28320 352
Вот эта звёздочка около буквы R как раз и сообщает, что резидентная порция разделяемой памяти сервера принудительно удерживается операционной системой резидентно.

> 1 1381386242 57000000 8192000 856 V 2000 0
> 2 1381386243 577d0000 663552 624 M 132 30
> 3 1381386244 57872000 8388608 856 V 2048 0
> 4 1381386245 58072000 8388608 856 V 2048 0
> 5 1381386246 58872000 8388608 856 V 2046 2
> 6 1381386247 59072000 8388608 856 V 2043 5
> 7 1381386248 59872000 8388608 856 V 1934 114
> 8 1381386249 5a072000 8388608 856 V 1149 899
> 9 1381386250 5a872000 8388608 856 V 1181 867
> 10 1381386251 5b072000 8388608 856 V 1036 1012
> 11 1381386252 5b872000 86863872 3256 V 330 20877
> 12 1381386253 60b49000 86863872 3256 V 1 21206
> 13 1381386254 65e20000 86863872 3256 V 1 21206
SHMVIRTSIZE 8000 ?
SHMADD 8192 ?
Хм, нас так не учили (хотя под Win можно и так). Говорили, что лучше всё в одном - первом, а не много маленьких. Более того, для HP-UX такая ситуация просто смертельна (в смысле производительности).

> owner всюду только root.
Не в курсе абсолютно - я запускал oninit из-под informix.

Последние известия.
Методом дихотомии удалось найти максимальные значения BUFFERS (320000) и SHMVIRTSIZE (49152) при которых сервер стартует (ну, ещё LOCKS 1000000 и CLENERS 4 - но это мелочи). Короче, Informix занимает 780080 Кб, и больше - никак. Любое увеличение этих параметров приводит к ошибке. (Внизу onstat и ipcs, если кому интересно - всё совпадает до байта). И всё-таки остаётся вопрос - а чего так мало-то? У меня на NT все сервера по 2Гб занимают (и даже 3 в одном месте, если память не изменяет). Не может ли это быть как-то связано с параметрами ядра? Вот что сказано в "MACHINE SPECIFIC NOTES":

SHMMAX: 33554432
SHMMIN: 1
SHMMNI: 128
SHMSEG: 128
SEMMNI: 128
SEMMNS: 4096
SEMMNU: 4096
SEMUME: 32
SEMMSL: 100
SEMMAP: 4096

И вот что мне удалось узнать:

> sysctl -a | grep shm
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmax = 33554432

> sysctl -a | grep sem
kernel.sem = 250 32000 32 128

Может ли кто-то это прокомментировать? Всё ли тут в порядке? А то суппорт (в лице Aasumа Mughalа :-) молчит как Зоя Космодемьянская на допросе...


P.S. Обещанные outputы.

> onstat -g seg

IBM Informix Dynamic Server Version 7.31.UD8 -- On-Line -- Up 00:30:29 -- 780080 Kbytes

Segment Summary:
id key addr size ovhd class blkused blkfree
12484610 1381386241 10000000 748470272 31164 R* 91360 6
13238297 1381386264 3c9cc000 50331648 1412 V* 936 5208
Total: - - 798801920 - - 92296 5214

(* segment locked in memory)


> ipcs

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x52564801 12484610 root 660 33554432 14 locked
0x52564802 12517379 root 660 33554432 14 locked
0x52564803 12550148 root 660 33554432 14 locked
0x52564804 12582917 root 660 33554432 14 locked
0x52564805 12615686 root 660 33554432 14 locked
0x52564806 12648455 root 660 33554432 14 locked
0x52564807 12681224 root 660 33554432 14 locked
0x52564808 12713993 root 660 33554432 14 locked
0x52564809 12746762 root 660 33554432 14 locked
0x5256480a 12779531 root 660 33554432 14 locked
0x5256480b 12812300 root 660 33554432 14 locked
0x5256480c 12845069 root 660 33554432 14 locked
0x5256480d 12877838 root 660 33554432 14 locked
0x5256480e 12910607 root 660 33554432 14 locked
0x5256480f 12943376 root 660 33554432 14 locked
0x52564810 12976145 root 660 33554432 14 locked
0x52564811 13008914 root 660 33554432 14 locked
0x52564812 13041683 root 660 33554432 14 locked
0x52564813 13074452 root 660 33554432 14 locked
0x52564814 13107221 root 660 33554432 14 locked
0x52564815 13139990 root 660 33554432 14 locked
0x52564816 13172759 root 660 33554432 14 locked
0x52564817 13205528 root 660 10272768 14 locked
0x52564818 13238297 root 660 33554432 14 locked
0x52564819 13271066 root 660 16777216 14 locked

------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 1245184 root 660 9
0x00000000 1277953 root 660 1
0x00000000 1310722 root 660 1
0x00000000 1343491 root 660 1
0x00000000 1376260 root 660 1
0x00000000 1409029 root 660 1

------ Message Queues --------
key msqid owner perms used-bytes messages