No, questo non succederà semplicemente perché due script Perl sono in esecuzione allo stesso tempo.
La spiegazione più probabile è che lo script stesso sia aperto per la scrittura mentre il sistema operativo sta tentando di leggere la sua riga shebang per determinare l'interprete da utilizzare.
Questo può verificarsi anche se un processo esterno sta tentando di aggiornare o modificare l'interprete Perl stesso o una delle librerie condivise da cui dipende. Nota che i permessi dei file generalmente non si applicano agli account di superutente, come root, quindi qualsiasi processo eseguito come superutente può ancora tentare di modificare l'interprete Perl nonostante non ci sia alcun bit +w
impostato.
(Ciò detto, gli strumenti di aggiornamento del sistema operativo più ben educati su sistemi operativi in stile POSIX scriveranno la versione aggiornata di un binario in un nuovo file sullo stesso file system, chiuderà il file una volta terminato e lo rinominerà nel originale (un'operazione atomica) - tale che l'inode collegato a /usr/bin/perl
non è mai esso stesso aperto per la scrittura. Pertanto, in un sistema ben funzionante, l'errore che si sta verificando non è qualcosa che dovrebbe mai verificarsi nella pratica) .
È possibile utilizzare il comando fuser
per vedere chi ha un file aperto, sia per lo script o per il suo interprete:
$ sudo fuser /usr/bin/perl -uv
USER PID ACCESS COMMAND
/usr/bin/perl: root 16579 f.... (root)python
fonte
2012-05-17 15:11:26
(questo è probabilmente più di una domanda di amministrazione di sistema - dipende OS semantica specifica e non è in alcun modo specifica per Perl, o anche per lingue interpretate - quindi in futuro, Server Fault potrebbe essere la sede più appropriata) –
tag perl cancellato – joewhitedelux