mensaje *** glibc detected *** malloc(): memory corruption: 0x081a2f80 *** sale al editar archivos con vi.

Era uno de esos días en que pienso "pa'qué diablos me levanté hoy" (en realidad no pensé eso de "diablos", sino otra cosa, pero mejor ahí la dejamos). Me disponía a generar unos scripts de ldap y me conecté a nuestro servidor linux SUSE9, con el usuario "oracle", e intenté abrir un archivo nuevo con el vi, cuando de pronto, ¡oh, sorpresa! Que sale el siguiente mensaje:

*** glibc detected *** malloc(): memory corruption: 0x081a2f80 ***

y pa'colmo de males, se quedó congelado el asunto, es decir, no volvió el "prompt". Guardé la calma y tranquilamente le di un "Cltr-C" para ver si volvía, y... ¡nada! Abrí otra sesión y le tuve que dar "kill -9" a mi proceso de vi. (Después descubrí que con Ctrl-Z me podía salir y luego ejecutar el kill desde esa misma sesión)

Fue un largo día, sin nada bueno qué recordar. Terminó al fin, y me fui a dormir.

En otro día menos nefasto, buscando en internet me encontré con un sitio donde recomendaban definir una variable de ambiente llamada MALLOC_CHECK_. Así procedí, pués:

export MALLOC_CHECK_=1

y volví a abrir el vi, el cual ya abrió y pude ver un archivo de prueba. Entonces, al cerrar el vi, salió el siguiente mensaje:

E138: Can't write viminfo file

el cual busqué de nuevo en internet, y me encontré con lo siguiente:

When you get error "E138: Can't write viminfo file"
check that no old temp files were left behind (e.g.
~/.viminf*) and that you can write in the directory of
the .viminfo file.
(http://www.mydatabasesupport.com/forums/shell/176820-vi-error.html)

Así que busqué en el home del usuario oracle los dichosos archivos .viminf*:

ls -ltra

y los borré todos (excepto .viminfo, si mal no recuerdo... o quizá ese también... mmm, pos mejor respáldenlo, por si acaso). Hecho esto, volví a abrir el vi y voilà!! Ya no hubo errores. Luego de terminada la misión, quité la variable MALLOC_CHECK_ (unset MALLOCK_CHECK_).

Listones.

Let's vi the world!

los fastidiosos caracteres "^M" al final de cada línea de texto

Cuando se generan archivos de texto en windows (en el Notepad, por ejemplo) y se copian a unix para trabajar con ellos, resulta que "aparecen" algunos caracteres "raros" al final de cada línea, que a veces se ven como la combinación de los caracteres: ^M. Esto se debe a que el formato que maneja windows para un fin de línea lleva dos caracteres: "new line" y "carriage return" (\n\r), mientras que en unix sólo se usa el de "new line" (\n). (En Mac se usa sólo "carriage return" (\r))

A mí me sucedió que me pasaron un archivo con una lista de números que yo tenía que comparar con otra lista y hacer algunas operaciones más, y al hacer la comparación con el comando diff, no obtuve los resultados esperados, y al guardar el resultado de la salida del diff, me di cuenta de que aparecían los dichosos caracteres ^M, y por eso todas las líneas entre ambos archivos eran distintas.

Entonces encontré la manera de convertir el archivo que provenía de windows para quitarle esos caracteres, con el comando siguiente:

tr -d '\015' <> unix-format.txt

También es posible hacer la operación inversa, cuando se quiere llevar un archivo de unix a windows:

sed -e 's/$/\r/' unix-format.txt > win-format.txt

Después encontré otro blog interesante al respecto. Transcribo (copy-paste) aquí el contenido y luego incluyo el URL:

If the ^M character is showing up in files while opening the file concerned, then follow these steps to convert it to a new line.
In vi use the following:

:%s/^M/\n/g

or with perl on the command line:

$ perl -pi.bak -e ’s/^M/\n/g’

NOTE: Be sure to create the ^M by typing ctrl V followed by ctrl M.

^M is ASCII 13 (Ctrl M), which is the carriage return.

Different operating systems use different symbols to set the end of a line/new line.
Unix uses newline (\n)
Mac uses carriage return (\r)
And Windows/DOS use both (\n\r)

To prevent the ^M from showing up in files, be sure to use the ASCII (text) mode when transfering text files.

http://blog.eukhost.com/webhosting/convert-m-to-newline-character-in-text-files/


Ahi quedó.

runInstaller: can't connect to X11 window server

Cierto día estaba tratando de instalar un OAS en Linux SuSE 9. Para ello, creé un usuario llamado "oracle", definí la variable DISPLAY=localhost:0.0, y al intentar correr el runInstaller, marcó el siguiente error:

can't connect to X11 window server using 'localhost:0.0' as the value of DISPLAY variable.

Con el usuario root, sin embargo, sí pude correr el runInstaller (no tuve que definir la variable localhost). Entonces, corrí el comando "cat /etc/hosts" y vi que sí aparecía el localhost, también le ejecuté "xhost +" y volví a intentar con oracle... sin éxito. Me metí a ver la configuración del X window server, intenté con la IP default en lugar de localhost en la variable DISPLAY, y nada.

Consultando en internet, encontré una nota en "SuSE linux community" en la siguiente dirección:

http://forums.suselinuxsupport.de/index.php?showtopic=7445&mode=linear

que decía lo siguiente:

enter this commands:
#DISPLAY=:0.0
#export DISPLAY
#xclock

hope this can help

Así que puse manos a la obra, me conecté con oracle, ejecuté el comando export DISPLAY=:0.0, y voilà: jaló.

Sin embargo, tenía las conexiones al xserver abiertas, pues había corrido el comando "xhost +". Para bloquear el acceso a mi xserver desde servidores no autorizados, corrí los comandos siguientes como root:

xhost -
xhost +local:

Después de esto, me conecté con oracle y volví a darle export DISPLAY=:0.0 y luego ./runInstaller y listo, funcionó.

Thanks, setisfiction. It did help :)

Cómo personalizar el mensaje de error 503 del Oracle Application Server

Cuando el Oracle Application Server encuentra un problema de red, o no recibe respuesta a un request externo antes del tiempo definido en el parámetro Timeout del Apache, muestra una página con letras rojas y un mensaje de error como el siguiente:

No Response from Application Web Server

There was no response from the application web server for the page you requested. Please notify the site's webmaster and try your request again later.

Yo intenté cambiar este mensaje agregando la entrada "ErrorDocument 503" en el archivo httpd.conf del Apache. Sin embargo, después de reiniciar el HTTP Server, limpiar cache, etc., seguía recibiendo la misma página con letras rojas.

Después de buscar archivos y configuraciones por donde se me ocurrió, encontré una nota que decía que a partir de cierta versión del OAS, el mensaje del parámetro "ErrorDocument 503" del httpd.conf es ignorado. También encontré una nota en metalink (note: 199291.1) que decía que al webcache se le podía configurar cuál página llamar cuando encuentre un error 503.

El archivo html que contiene este mensaje de error, es:

$ORACLE_HOME/webcache/files/network_error.html

Se puede modificar ese archivo, o bien, crear otro y decirle al webcache donde encontrarlo. Para la segunda opción, hay que entrar al administrador del webcache (Enterprise Manager), de ahí a Sites y luego a la liga "Define" Default Error Pages que se encuentra en "Defaults and Global Settings".

Luego del cambio, hay que reiniciar el webcache.

Oracle Messenger no se puede conectar

En alguna ocasión, después de cierto tiempo de haber utilizado el Oracle Collaboration Suite, un buen día el Oracle Messenger no se podía conectar. Marcaba algo como lo siguiente:

Sign In Failure. Unable To Connect To The Server, Please Try Again Later

En español sale algo así como:

Fallo de conexión. No se ha podido conectar al servidor. Vuelva a intentarlo más tarde.

A continuación describo lo que hice:

1. Corrí el comando "$ORACLE_HOME/imeeting/bin/rtcctl getstate -v", el cual arrojó el siguiente resultado:

ID COMPONENT_NAME TYPE STATUS NUM_PROCS
10007 rtc-connmgr connmgr UP 2
10000 rtc-confsvr confsvr UP 4
10006 rtc-imrtr imrtr STANDBY 1
10008 rtc-voiceproxy voiceproxyUP 1
10004 rtcpm rtcpm UP 1
10003 rtc-rdtr rdtr UP 1
10002 rtc-mx mx UP 1

Como se ve, el imrtr, que es el instant messenger, no estaba corriendo. Además, el log más reciente que se encuentra en $ORACLE_HOME/imeeting/logs/connmgr indicaba lo siguiente:

S*05/21/07 20:04:39 Bounce back to client for no JAX connection: shg
i.05/21/07 20:04:39 pollconn: closed [8]

Según una nota que encontré en metalink (Note: 356411.1), esto puede deberse a que la base de datos falló, se apagó súbitamente, etc., lo cual dejó un archivo sin cerrar y esto a su vez causó el problema.

2. Detuve el RTC ($ORACLE_HOME/imeeting/bin/rtcctl stop)

3. Detuve el OC4J_imeeting (opmnctl stopproc process-type=OC4J_imeeting)

4. Detuve el resto de las aplicaciones (opmnctl stopall)

5. Verifiqué que no quedaran procesos de imeeting corriendo (ps -ef | egrep imeeting). Si hubieran quedado, los hubiera matado (kill -9 )

6. Después de llevar a cabo los pasos anteriores, moví los archivos que se llamaban "*pid*" que quedaron en los subdirectorios de $ORACLE_HOME/imeeting/tmp hacia un directorio temporal (find $ORACLE_HOME/imeeting/tmp -name "*pid*" -exec mv {} ~/local/tmp/ \;)

7. Moví el archivo xcp.pid que estaba dentro de $ORACLE_HOME/imeeting/im/support hacia un directorio temporal (mv $ORACLE_HOME/imeeting/im/support/xcp.pid ~/local/tmp)

8. Levanté las aplicaciones de nuevo (opmnctl startall)

9. Corrí el comando "$ORACLE_HOME/imeeting/bin/rtcctl getstate -v" de nuevo, y ahora arrojó el siguiente resultado:

ID COMPONENT_NAME TYPE STATUS NUM_PROCS
10007 rtc-connmgr connmgr UP 2
10000 rtc-confsvr confsvr UP 4
10006 rtc-imrtr imrtr ACTIVE-OK 1
10008 rtc-voiceproxy voiceproxyUP 1
10004 rtcpm rtcpm UP 1
10003 rtc-rdtr rdtr UP 1
10002 rtc-mx mx UP 1

8. Ejecuté el Oracle Messenger y ahora sí me pude conectar.

9. Me fui por unos bien merecidos tacos y un par de cervezas.

**************************************************************

En otra ocasión salía el mismo error al querer conectarme con el Oracle Messenger, pero cuando corría el comando rtcctl getstate, todo estaba bien. Entonces corrí el mismo comando rtcctl, pero con la opción de runTests, "$ORACLE_HOME/imeeting/bin/rtcctl runTests" y obtuve lo siguiente:

TEST NAME SUCCESS
mtgtest true
dbtest true
apptest true
proxytest false
emailtest true
imtest false
servletAccessTesttrue

Y después de buscarle, encontré lo siguiente en el Real-Time Collaboration Administrator's Guide:

If users are able to sign in to the Oracle Messenger, and the rtcctl getState command shows that all Oracle Messenger components are running, but the imtest shows as failed in the Status report under the System tab, you should check the connectivity to the database from the Oracle Presence server. Make sure that the tnsnames.ora file on the Applications tier is correctly configured to let you to run sqlplus from $ORACLE_HOME to the database containing the RTC schema.

Y revisando, efectivamente el tnsnames.ora del home de aplicaciones no tenía la entrada de la BD del OCS, por lo que la agregué y se solucionó el problema.

Cómo obtener el group ID y el User ID en unix

Al menos en linux SuSE 9, se puede hacer lo siguiente:

1. Para saber el userID:

egrep username /etc/passwd

El userID es el que aparece en el tercer campo (los campos se separan con ":"), por ejemplo, si el resultado del comando anterior es la siguiente línea:

oracle:x:1000:1000:oracle admin:/u00/app/oracle:/usr/bin/ksh

entonces el userID es 1000. El cuarto campo indica el groupID (que también es 1000).

2. Para saber el groupID, también se puede hacer lo siguiente:

egrep groupname /etc/group

De igual manera que en punto anterior, el ID es el tercer campo

Usuarios no se pueden logear al Portal después de sincronizar eDirectory de Novell con OID

Se decidió que un directorio de Novell (eDirectory) se sincronizaría con el OID para tener la misma población de usuarios y que cada usuario tuviera el mismo password en ambos sistemas. Se probó un driver que desde Novell eDirectory "sincroniza" a las personas (es decir, "copia" su información almacenada en el eDirectory) hacia el OID y funcionó bien.

Sin embargo, los usuarios no podían logearse al Oracle Portal, pues éste marcaba un error después de dar usuario/password. Se revisó en el ODM la información de los atributos de un usuario que sí se podía logear al Portal con uno que no podía, y se encontró que el que no podía tenía el atributo orclpassword nulo, es decir, no tenía nada. Entonces se checaron los demás atributos y se encontró que el atributo "uid" también estaba nulo para el usuario que no se podía logear al Portal, no así para el que sí podía.

Entonces, se procedió agregar dicho atributo en el driver del Novell eDirectory y se le asignó el mismo valor que al atributo "cn". Teniendo el atributo "uid" con un valor diferente de nulo, ya se le generó automáticamente al usuario el atributo orclpassword en la sincronización, y ya se pudo logear al Oracle Portal.

OC4J no levanta (OAS 10g 10.1.4)

Había una vez una instalación de OAS 10g en tres capas:

1. Infraestructura
2. Middle Tier (Portal)
3. Web Cache

En cierta ocasión, después de bajar todo el sistema, al querer levantar la infraestructura notamos que tardaba mucho tiempo en ejecutarse el comando "opmnctl startall", y al final marcaba el error siguiente:

ias-component/process-type/process-set:
OC4J/OC4J_SECURITY/default_island

Error
--> Process (pid=14740)
time out while waiting for a managed process to start
Log:
/u00/app/oracle/product/oas10g/infra10o1/opmn/logs/OC4J~OC4J_SECURITY~default_island~1

La Base de Datos levantó bien, el Listener también, el HTTP Server también, pero el OC4J decía "Down" cuando se ejecutaba el comando "opmnctl status". Al revisar el log indicado por el error anterior, éste decía (sólo muestro parte del mensaje):

07/03/04 21:35:33 [warning] cannot open connection, type=*
oracle.idm.connection.ConnectionException: cannot open ldap context, serialNumber=11, type=ldap, operation=open

... (más del stack trace de java) ...

Caused by: javax.naming.NamingException: Unable to establish initial secure conn
ection to Oracle Internet Directory Server. Please verify that the correct Oracl
e Internet Directory Server parameters are specified in /u00/app/oracle/product/
oas10g/infra10o1/config/ias.properties. Make sure that the Oracle Internet Direc
tory Server specified in OIDhost, OIDsslport is up and running. Base Exception :
javax.naming.CommunicationException: prod26db.itesm.mx:636 [Root exception is j
ava.net.ConnectException: Connection refused]

El ODM (Oracle Directory Manager) se "congelaba", o bien, se quedaba "colgado" después de dar usuario/password y host/puerto. Esto empezó a levantar sospechas de que el problema se trataba de comunicación con el OID. Después de buscar mucho y no encontrar nada que nos ayudara, preguntamos a un experimentado consultor de OAS, quien nos dio el siguiente procedimiento:

1. Revisar el contenido de la tabla ODS.ODS_PROCESS
2. Respaldar dicha tabla (hicimos un simple "spool" desde sqlplus)
3. Dar de baja todo con "opmnctl stopall" (obviamente, bajar todas las capas)
4. Truncar la tabla ODS.ODS_PROCESS
5. Levantar todo con el "opmnctl startall"

Así procedimos, y todo levantó bien.

NOTA: Esto nos trajo consecuencias, como por ejemplo, que no levantara el servidor de replicación (OIDREPLD), el cual lo tuvimos que levantar a mano posteriormente con el comando "oidctl server=OIDREPLD instance=1 start".

Habrá que revisar qué más implicaciones tiene el truncar dicha tabla. Se los dejo de tarea, así como el investigar por qué sucedió eso.