Publicado el Dejar un comentario

Servicio Postgresql en mantenimiento en Solaris 10

postgresql en mantenimiento

De pronto el servidor de reportes de Pentaho versión 5.4 dejó de funcionar, la aplicación no era cargada por Tomcat y su archivo log mostraba lo siguiente:

SEVERE: The web application [/pentaho] created a ThreadLocal with key of type [java.lang.InheritableThreadLocal] (value [java.lang.InheritableThreadLocal@4bace654]) and a value of type [org.springframework.security.providers.UsernamePasswordAuthenticationToken] (value [org.springframework.security.providers.UsernamePasswordAuthenticationToken@fc3ceceb: Principal: org.springframework.security.userdetails.User@0: Username: admin; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: Admin; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: Admin]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

Al parecer la base de datos Postgresql no estaba funcionando. Al ejecutar el comando siguiente con privilegios de root
svcs postgresql
para saber el estado del servicio regresaba lo siguiente:
bash-3.2# svcs -p postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
maintenance Dec_04 svc:/application/database/postgresql:version_94

La versión 9.4 de Postgresql estaba en estado de mantenimiento (maintenance), al parecer, debido a un corte de energía, la base de datos no se apagó por completo.

Se revisa por qué motivo el servicio quedó en mantenimiento ejecutando:

bash-3.2# svcs -x postgresql
svc:/application/database/postgresql:version_94 (PostgreSQL RDBMS)
State: maintenance since Fri Dec 04 16:52:05 2020
Reason: Method failed.
See: http://sun.com/msg/SMF-8000-8Q
See: postgres_94(5)
See: /var/svc/log/application-database-postgresql:version_94.log
Impact: This service is not running.

Revisamos el archivo log que indica el el comando anterior y la última línea mostraba lo siguiente:

[ Dec 4 16:51:04 Executing stop method (“/lib/svc/method/postgresql stop”) ]
waiting for server to shut down………………………………………………………[ Dec 4 16:52:05 Method or service exit timed out. Killing contract 1187 ]

Al parecer no se completo correctamente el apagado de la Base de Datos.

Así que se revisó si algún proceso del servicio aún había quedado corriendo con el comando:

bash-3.2# svcs -p postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
maintenance Dec_04 svc:/application/database/postgresql:version_94

Lo que mostró que no había otros procesos del servicio postgresql 9.4 corriendo. Si los hubiera habido, hubiera sido necesarios “matarlos” con el comando kill.

Y por último, para activar o poner nuevamente en línea el servicio de Postgresql se corre el comando:

bash-3.2# svcadm clear svc:/application/database/postgresql:version_94

Corremos nuevamente el comando svcs para verificar que el servicio está corriendo de nuevo:

-bash-3.2$ svcs postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
online 18:16:25 svc:/application/database/postgresql:version_94

Efectivamente, el servicio está de nuevo en línea. Iniciamos nuestro servidor de reportes de Pentaho y listo, el error se fue.

¡Espero y les sirva! ¡Hasta la próxima!

Publicado el Dejar un comentario

Recuperación. Necesita reparar su PC. Windows 10.

codigo de error 0xc000000d

Un sobrino me llama diciéndome que después de instalar unas actualizaciones de Windows 10 y reiniciar la computadora le apareció a terrorífica pantalla azul de Windows con el siguiente mensaje:

“Recuperación. Necesita reparar su PC o dispositivo. Error inesperado. Código de error: 0xc000000d. Debes utilizar las herramientas de recuperación. Si no dispones de los medios de instalación (como un disco o dispositivo USB), ponte en contacto con tu administrador de PC o con el fabricante del PC o dispositivo”.

Y que en los talleres informáticos le decían que la única solución era formatear la máquina nuevamente. Sin embargo, mi sobrino no quería perder las licencias que estaban configuradas a su máquina, así que acudió a mi para ver si tenía otra solución.

Así que comencé a buscar en internet posibles soluciones y apliqué varias pero sin resultados. Hasta que encontré una respuesta en este foro y decidí probar ésta con algunos pequeños cambios y.. ¡que funciona!

Aquí reproduzco los pasos, pero para eso necesitamos un disco u otro medio de instalación o recuperación de Windows 10:

  1. Iniciamos o “booteamos” con el medio de recuperación o instalación.
  2. Su es medio de instalación cuando aparezca la ventna de instalar windows seleccionamos reparar windows en lugar de instalar.
  3. En el menú de recuperación, seleccionamos una ventana de comando o “command prompt” para abrir una ventana de DOS.
  4. Identificamos la partición EFI (es donde se deberían encontrar nuestros archivos de arranque) para eso usamos el comando diskpart:
    diskpart <Entrar>
    list disk <Entrar>
    sel disk n <Entrar> (donde "n" es el número de disco donde están las particiones que nos lo debe dar el comando anterior)
    list vol <Entrar>
    sel vol n <Entrar> (donde "n" es el número de volumen donde residen los archivos de arranque el cual lo obtendremos con el comando anterior, podemos identificarlo fácilmente ya que es el que tiene menor capacidad, aproximadamente unos 500 Megabytes o menos)
    assign letter=N: <Enter> (donde "N" es alguna letra que no esté asignada ya a algunos de los volúmenes o unidades de disco, en mi caso seleccioné la letra "J")
    exit <Enter>
    J: <Enter> (si asignaste otra letra al volumen cambia la letra "J" por la letra que hayas asignado en tu caso, esto nos cambiara a el volumen de arranque)
  5. Ejecuta el siguiente comando:
    bcdboot n:\windows /s J: /f UEFI <Entrar> ("n" corresponde a la unidad o volumen del disco duro donde está instalado el Windows 10, en mi caso era la unidad E; y "J" es la letra que asigné al volumen donde se encuentran los archivos de arranque, cámbiala a la que hayas asignado en el paso 4)
  6. Cierra la ventana de comando y reinicia el equipo o computadora. el reinicio puede tardar un buen rato.

Si pueden respaldar la información antes de realizar estos pasos mucho mejor. Recuerden siempre hacer respaldo de sus archivos en unidades externas como discos portátiles o memorias USB.

Espero y esta solución también les ayude. Cualquier comentario es bienvenido.

Publicado el Dejar un comentario

Visual Studio Code pantalla blanca Centos 7

Instalé Visual Studio Code en una máquina con sistema operativo Linux CentOS 7 y al ejecutarlo en forma remota a través de ssh sólo me mostraba una pantalla en blanco.

Después de mucho “googlear” encontré la respuesta. Resulta que hay un fallo con algunos de los componentes cuando se corre de forma remota a través de ssh (x11 forwarding).

Para evita este fallo hay que ejecutar VS Code con el parámetro –no-xshm así:

code –no-xshm

Esto mostrará VS Code correctamente:

Aquí puedes ver el reporte del fallo y la solución.

Espero y les sea útil.

¡Hasta la próxima!