O.T. Un problema de mantenimiento

[José Vicente Beltrán]

Me ocurre algunas veces en sistemas complejos, red local con muchos terminales combinada con accesos via RDP (terminal services)
uso DBF con sus indices y un ejecutable comun a todos los clientes, en el servidor.
Cuando toca mantenimiento del sistema, procuro que sea siempre durante las horas nocturnas que no hay nadie trabajando y actuando siempre con credenciales de administrador, al intentar sustituir, modificar o actualizar algún archivo, da igual que sea el EXE, los indices o las DBF, sale un mensaje de que el archivo no se puede renombrar, modificar etc. porque está en uso por otra aplicación'.

Les prometo que en el servidor no existe rastro de que ningun proceso tenga abierto ninguno de los archivos en cuestión; pero a pesar de ello no hay nada que hacer a menos que se apague y vuelva a arrancar el servidor, cosa nada practica en este tipo de sistemas.

¿Alguien sabe por qué puede ocurrir esto? o en su defecto, ¿Hay forma de liberar los archivos sin tener que apagar el servidor?

El 'Unlocker' y otras herramientas similares no funcionan.
Gracias por su ayuda.

[pablovidal]

Busca los procesos en el administrador de tareas y desde hay matas el proceso.-

[José Vicente Beltrán]

Gracias por contestar, Pablo

Eso es lo primero que hago para estar seguro de que nadie está conectado, y por supuesto que nadie se haya dejado abierta una sesión por descuido o algo así.
No existe ningún rastro en el servidor de que se esté corriendo el ejecutable en cuestion pero aún así algunos archivos están bloqueados como digo.

[hmpaquito]

José Vicente,

Las cosas raras siempre tienen que ver con antivirus.
¿ Has probado a desactivar el antivirus temporalmente ? Probablemente te ayudaria si supieras el puesto/sesion/usuario que abrio el programa que sigue vivo.

Saludos

[José Vicente Beltrán]

hmpaquito, no habia pensado en el antivirus, pero ahora que lo dices...., investigaré en esa dirección.
En cuanto a la sesión causante del problema no puedo saberlo porque interactuo directamente sobre el servidor y TEORICAMENTE todas las sesiones están cerradas.

Gracias

[Carlos Mora]

Una pregunta Vicente: ¿Que sistema operativo tiene el servidor? Porque en Win Server 2008, en las Herramientas Administrativas hay como ver que archivos están abiertos y por quien. Tambien puedes usar DameWare Utilities, tiene una opción para ver los archivos abiertos y por quien.
Me ha pasado que a veces el programa casca, y si bien sale el mensaje de error, el proceso no se muere, el exe queda en memoria pero invisible, y con los archivos abiertos. Cuando tienes + de 100 PCs conectadas al servidor...

Un saludo

[Carlos Mora]

Otra idea: si es por sustituir el exe, aunque no lo puedo borrar si lo puedes renombrar, entonces le cambias el nombre y copiar el exe nuevo.

[José Vicente Beltrán]

¿Que sistema operativo tiene el servidor? Porque en Win Server 2008, en las Herramientas Administrativas hay como ver que archivos están abiertos y por quien.

Me ha ocurrido en server 2008 pero tambien en server 2003

Tambien puedes usar DameWare Utilities, tiene una opción para ver los archivos abiertos y por quien.

No conocía la herramienta, la probaré.

Me ha pasado que a veces el programa casca, y si bien sale el mensaje de error, el proceso no se muere, el exe queda en memoria pero invisible, y con los archivos abiertos.

Creo que es ese el problema, ahora me gustaría saber como evitarlo o en el peor de los casos como solucionarlo de la mejor forma posible

Gracias a todos por las sugerencias, me ayudan bastante

[José Vicente Beltrán]

Otra idea: si es por sustituir el exe, aunque no lo puedo borrar si lo puedes renombrar, entonces le cambias el nombre y copiar el exe nuevo.

Eso lo hago con frecuencia pero hay veces que el S.O. no permite ni renombrar, y es ahí cuando me pongo de los nervios....

[hmpaquito]

José Vicente,

Siguiendo con la idea de Carlos Mora y tu sospecha, he visto que ya hace años que en mi errsysw.prg (local) sustitui TODOS los QUIT por MiQuit()

Code: Select all  Expand view

FUNCTION MiQuit()

PostQuitMessage(0)
SysRefresh()                  // Importante !!

CLOSE DATABASES              // Quiza inncesario, QUIT ya cierra los ficheros.
__Quit()

RETURN NIL                   // <-- Inalcanzable ;-)

Esto es porque puede ocurrir que solamente con QUIT el programa quede abierto para Windows. Con PostQuitMessage() se fuerza a que Windows lo cierre tambien.
Espero te sea de utilidad.

[José Vicente Beltrán]

PostQuitMessage(0)
SysRefresh()

Alguna vez en el pasado use la primera función pero sin saber muy bien que hacía, la probaré ahora con sysrefresh(), a veces las cosas son mas simples de lo que parecen

[Patricio Avalos Aguirre]

Hola

lo otro que deberias tener en cuenta son los usuarios de TS, lo cual casi siempre dejan los sistemas abiertos
con la aplicacion "Administrador de Servicios de Terminal Server"

ahi puedes ver quien esta conectado

[José Vicente Beltrán]

Gracias Patricio, pero eso tambien lo compruebo antes de comenzar el proceso de mantenimiento.

[ltorres]

Yo tenía ese problema, porque encontraba sesiones abiertas de usuarios en el Administrador de tareas- Pestaña de Usuarios y procedía a cerrar las sesiones de estos usuarios.

Ojala te ayude.


Luis

[José Vicente Beltrán]

Gracias a todos por su interes, las diversas opiniones, entre otras, me han llevado a localizar el origen del problema, y tiene mucho que ver con la configuracion del protocolo SMB en las redes con diversos sistemas operativos funcionando conjuntamente cuando el servidor corre windows server 2008 en cualquiera de sus versiones.

Básicamente, el problema desaparece cuando se desactiva el SMB2 tanto en el servidor como en los clientes, además de hacer que los indices se vuelvan muy duros de romper, con lo que matamos dos pájaros de un tiro.

De nuevo gracias al foro ya que sin su insustituible ayuda no habría sido capaz de dar con la solución