Una pequeña solicitud: leo las preguntas Perl de Stack Overflow todos los días y respondo/contribuyo cuando puedo; ¡hoy necesito la ayuda de la comunidad!¿Qué podría hacer que las llamadas al sistema Perl comiencen a fallar?
Perl setup: ejecuto Active Perl 5.8.8 en Windows. La instalación se realiza en la unidad local de nuestro servidor de departamento, que también se comparte con la red. Todos los usuarios del departamento ejecutan Perl en sus propias PC apuntando a Perl instalado en la red. Esto ha funcionado durante años y no está causando ningún problema, pero es una información necesaria para comprender el problema.
El servidor en cuestión también es nuestro servidor "cron" (Tarea programada), que maneja una variedad de tareas de automatización. De repente, la semana pasada, las llamadas al sistema en scripts de Perl (en el servidor) comenzaron a fallar (detalles a continuación). Al principio, sospechaba de una instalación corrupta de Perl, pero todas las PC cliente todavía pueden ejecutar los mismos scripts de Perl sin ningún problema, lo que me lleva a pensar que es un problema de servidor. He reiniciado el servidor dos veces, y el problema es persistente, ¡así que necesito ayuda!
Éstos son algunos ejemplos de los diversos forma que las llamadas al sistema están fallando, se reducía a Perl de una sola línea:
% perl -e "system('dir')"
Eso debería imprimir una lista "dir", pero en su lugar se abre un sub-shell . Si escribo "salir", puedo salir del subconjunto, y estoy de vuelta en el intérprete de comandos original (confirmado al examinar el historial del intérprete usando la tecla de flecha ARRIBA).
% perl -e "print `dir`"
Esto realmente se cuelga. Nada sucede en absoluto. Si presiono Ctrl-C para cancelar el proceso, aparece el mensaje "Terminación en la señal SIGINT (2)" y aparece el mensaje de DOS. Pero, cualquier comando futuro en el indicador de DOS (incluso presionando ENTER) causa el error "El proceso intentó escribir en un conducto inexistente". Debe salir del indicador de DOS ya que es inútil.
Última ejemplo:
% perl -e "system('Z:/Scripts/rebuild.pl')"
'ebuild.pl' no se reconoce como un comando interno o externo, programa o archivo por lotes.
En este caso, Perl cambia las barras diagonales (/) a DOS/Windows back-slashes(), lo que ha funcionado bien durante años. Pero, Perl interpreta el "\ r" al comienzo del nombre del archivo "rebuild.pl" como un retorno de carro (creo) y busca el "ebuild.pl" restante. Las llamadas a otros nombres de secuencia de comandos cuyos caracteres no pueden malinterpretarse de esa manera dan como resultado los cuelgues anteriores (si usa los trazos atrás) de subcajas que se abren (para las llamadas al sistema()).
No estoy solo perplejo por esto - ¡Estoy desesperado! Los trabajos "cron" de nuestro servidor de departamento son inútiles en este momento ya que usamos muchas llamadas al sistema.
Una vez más, no creo que se trate de una instalación corrupta de Perl, ya que los usuarios de la red pueden funcionar correctamente. Entonces, ¿qué podría suceder en una máquina individual (no vinculada a la instalación de Perl) que podría causar que las llamadas al sistema de Perl fallen así?
ajustes de Medio Ambiente, conforme a lo solicitado:
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\engmodem\Application Data
CDSROOT=Z:\Cadence\SPB_16.5
CDS_CONCEPT_NOSPLASH=TRUE
CDS_LIC_ONLY=1
CDS_SITE=Z:\Cadence\Sites\16.5
CHDL_LIB_INST_DIR=%CDSROOT%
CLIENTNAME=USENTUTTLJL3C
ClusterLog=C:\WINDOWS\Cluster\cluster.log
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=CORPUSAPP5
ComSpec=C:\WINDOWS\system32\cmd.exe
CONCEPT_INST_DIR=%CDSROOT%
FP_NO_HOST_CHECK=NO
HOMEDRIVE=H:
HOMEPATH=\
HOMESHARE=\\PF1\HOME
ICMHOME=Z:\Software\PTC\INTERC~1
INSTDIR=%CDSROOT%
LOGONSERVER=\\ENGMAHO5
LSF_BINDIR=Z:\Software\LSF\bin
LSF_ENVDIR=\\hwc151\LSF_6.2\etc
MESSAGE=BROADCAST
NUMBER_OF_PROCESSORS=2
OA_PLUGIN_PATH=%CDSROOT%\Share\oaPlugIns
OS=Windows_NT
Path=C:\Program Files\Legato\nsr\bin;Z:\oracle\ora92\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Windows Resource Kits\Tools\;Z:\Software\Perl\5.8.8\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\Program Files\Support Tools\;Z:\Software\LSF\bin;C:\Program Files\PHP\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\EMC RepliStor;C:\GitStack\python;C:\GitStack\python\Scripts;C:\GitStack\git\cmd;Z:\Scripts;Z:\bin;Z:\Cadence\SPB_16.5\tools\bin;Z:\Cadence\SPB_16.5\tools\fet\bin;Z:\Cadence\SPB_16.5\tools\pcb\bin;Z:\Cadence\SPB_16.5\OpenAccess\bin\win32\opt
PATHEXT=.COM;.EXE;.BAT;.PL;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.VBS
PCB_LIBRARY=16
PERL5SHELL=cmd
PHPRC=C:\Program Files\PHP\
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 29 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1d01
ProgramFiles=C:\Program Files
PROMPT=$P$G
PULLUP_DIFF_PAIRS=TRUE
SESSIONNAME=RDP-Tcp#1
SystemDrive=C:
SystemRoot=C:\WINDOWS
TZ=EST5EDT
VISUALSVN_SERVER=C:\Program Files\VisualSVN Server\
WF_RESOURCES=Z:\oracle\ora92\WF\RES\WFus.RES
windir=C:\WINDOWS
No estoy seguro de qué tan relevante es esto, pero ¿podría ser un error de permisos? ¿El usuario que ejecuta el script no tiene los permisos necesarios para ejecutar los comandos del sistema? Solo un pensamiento. –
El usuario está en el grupo Administradores local, el mismo usuario bajo el cual las Tareas programadas se han estado ejecutando durante años. – jimtut
Quizás esta pregunta sea más adecuada para ServerFault o SuperUser? – TLP