пятница, 21 сентября 2012 г.

Solaris 10: ZONECFG - Segmentation Fault

В свое время я написал серию статей о конфигурировании зон Solaris 10. Недавно мне пришлось тряхнуть стариной и вспомнить о своем конфигураторе. И вдруг - внезапно! - обнаружилось, что ни на одной машине мой конфигуратор не работает.

Обнаружилась занятная ошибка:

root @ pegasus /patch # zoneinst.sh zone1.cfg
Segmentation Fault - core dumped
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
zone1: No such zone configured
zone1: No such zone configured
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
Zone zone1 configured.
______________________
Press to install zone or to cancel.
^C

Более того, ошибка проявлялась сразу же при первом запуске zonecfg:

+ /usr/sbin/zonecfg -z zone1 create; set autoboot=true; set zonepath=/data/zone1; 
Segmentation Fault - core dumped


Вскрытие сначала привело сюда:

root @ ktulhu /patch # ldd /usr/sbin/zonecfg libz.so.1 => /usr/local/lib/libz.so.1 libz.so.1 (SUNW_1.1) => (version not found)

А затем сюда:

root @ ktulhu /patch # find / -name libz.so.1
/usr/lib/amd64/libz.so.1
/usr/lib/libz.so.1
/usr/local/lib/libz.so.1
^C
root @ ktulhu /patch # echo $LD_LIBRARY_PATH
/lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib:
root @ ktulhu /patch # export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH
root @ ktulhu /patch # echo $LD_LIBRARY_PATH
/usr/lib:/lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib:
root @ ktulhu /patch # ldd /usr/sbin/zonecfg
libzonecfg.so.1 => /usr/lib/libzonecfg.so.1
libl.so.1 => /usr/lib/libl.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libtecla.so.1 => /usr/lib/libtecla.so.1
libzfs.so.2 => /usr/lib/libzfs.so.2
libbrand.so.1 => /usr/lib/libbrand.so.1
libc.so.1 => /usr/lib/libc.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libuuid.so.1 => /usr/lib/libuuid.so.1
libnvpair.so.1 => /usr/lib/libnvpair.so.1
libsysevent.so.1 => /usr/lib/libsysevent.so.1
libsec.so.1 => /usr/lib/libsec.so.1
libpool.so.1 => /usr/lib/libpool.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libproc.so.1 => /usr/lib/libproc.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libxml2.so.2 => /usr/lib/libxml2.so.2
libmp.so.2 => /usr/lib/libmp.so.2
libmd.so.1 => /usr/lib/libmd.so.1
libcurses.so.1 => /usr/lib/libcurses.so.1
libm.so.2 => /usr/lib/libm.so.2
libdevinfo.so.1 => /usr/lib/libdevinfo.so.1
libdevid.so.1 => /usr/lib/libdevid.so.1
libgen.so.1 => /usr/lib/libgen.so.1
libavl.so.1 => /usr/lib/libavl.so.1
libefi.so.1 => /usr/lib/libefi.so.1
libadm.so.1 => /usr/lib/libadm.so.1
libumem.so.1 => /usr/lib/libumem.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libexacct.so.1 => /usr/lib/libexacct.so.1
librtld_db.so.1 => /usr/lib/librtld_db.so.1
libelf.so.1 => /usr/lib/libelf.so.1
libctf.so.1 => /usr/lib/libctf.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libz.so.1 => /usr/lib/libz.so.1

То есть, для устранения ошибки достаточно было правильно установить переменную LD_LIBRARY_PATH, причем желательно это сразу сделать в глобальном профиле /etc/profile.

Причем, как обычно и случается, оказалось также, что ничто не ново под луной и все это уже однажды было. :)

Дальнейшее детальное исследование обнаружило, что в свежеустановленных Солярисах данная проблема не наблюдается, но вот в сильно кастомизированных серверах, с установленными дополнительными пакетами, весьма вероятна.

Резюмируя вышесказанное, следует заметить, что в реальных системах следует весьма вдумчиво подходить к формированию окружения и, главное, формировать переменную LD_LIBRARY_PATH таким образом, чтобы системные библиотеки находились первыми.