Una piccola richiesta: leggo ogni giorno le domande Perl di Stack Overflow e rispondo/contribuisco dove posso; oggi ho bisogno dell'aiuto della comunità!Cosa potrebbe causare il fallimento delle chiamate del sistema Perl?
Configurazione Perl: eseguo Active Perl 5.8.8 su Windows. L'installazione si trova sull'unità locale del nostro server dipartimentale, anch'essa condivisa con la rete. Tutti gli utenti del dipartimento eseguono Perl sui propri PC puntando su questo Perl installato in rete. Questo ha funzionato per anni, e non sta causando un problema, ma è una parte delle informazioni necessarie per comprendere il problema.
Il server in questione è anche il nostro server "cron" (operazione pianificata), che gestisce una varietà di attività di automazione. All'improvviso, la scorsa settimana, le chiamate di sistema negli script Perl (sul server) hanno iniziato a fallire (dettagli sotto). All'inizio sospettavo un'installazione Perl corrotta, ma tutti i PC client possono ancora eseguire gli stessi script Perl senza alcun problema, portandomi a pensare che si tratti di un problema del server. Ho riavviato il server due volte e il problema è persistente, quindi ho bisogno di aiuto!
Ecco alcuni esempi dei vari modo in cui le chiamate di sistema stanno fallendo, riassunta in Perl one-liners:
% perl -e "system('dir')"
Questo dovrebbe stampare un elenco "dir", ma invece si apre un sotto-shell . Se digito "exit", posso uscire dalla sub-shell, e sono tornato nella shell originale (confermato esaminando la cronologia della shell usando il tasto freccia SU).
% perl -e "print `dir`"
Questo blocca in realtà. Non succede nulla Se I Ctrl-C per uccidere il processo, ottengo il messaggio "Terminating on signal SIGINT (2)" e il prompt di DOS ritorna. Ma, eventuali comandi futuri nel prompt di DOS (anche solo premendo ENTER) causano l'errore "Il processo ha cercato di scrivere su una pipe inesistente.". Devi uscire dal prompt di DOS perché è effettivamente inutile.
Ultimo esempio:
% perl -e "system('Z:/Scripts/rebuild.pl')"
'ebuild.pl' non è riconosciuto come comando interno o esterno, un programma eseguibile o un file batch.
In questo caso, Perl scambia le barre di avanzamento (/) a barre indietro DOS/Windows(), che ha funzionato correttamente per anni. Ma, Perl sta interpretando "\ r" all'inizio del nome file "rebuild.pl" come un carriage-return (credo) e cercando il rimanente "ebuild.pl". Chiama ad altri nomi di script i cui caratteri non possono essere interpretati erroneamente come quello che si verifica nel blocco precedente (se si utilizzano i backtick) delle sotto-shell che vengono aperte (per le chiamate di sistema()).
Non sono solo perplesso da questo - sono disperata! I lavori "cron" del nostro server dipartimentale sono inutili in questo momento poiché utilizziamo molte chiamate di sistema.
Ancora una volta, non penso che questa sia una installazione Perl danneggiata, dal momento che gli utenti della rete possono funzionare correttamente. Quindi, cosa potrebbe accadere su una singola macchina (non legata all'installazione stessa di Perl) che potrebbe causare il fallimento delle chiamate di sistema di Perl in questo modo?
impostazioni di ambiente, come richiesto:
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
Non so quanto sia rilevante, ma potrebbe essere un errore di autorizzazione? L'utente che esegue lo script non ha le autorizzazioni necessarie per eseguire i comandi di sistema? Solo un pensiero. –
L'utente si trova nel gruppo Administrators locale, lo stesso utente in cui le attività pianificate sono in esecuzione da anni. – jimtut
Forse questa domanda è più adatta per ServerFault o SuperUser? – TLP