O script Python funciona do terminal, mas falha no programador, para gravar na unidade externa

Question

Eu estou tentando usar um script Python para ler / escrever de um disco externo no linux, o que funciona bem. O problema surge quando uso um agendador de tarefas para executar o programa em Python.

Estou executando tudo isso em um Rocks Cluster (a versão linux é o CentOS 6.5) e o job scheduler é o Sun Grid Engine (SGE). Eu montei o disco externo para que todos os usuários tenham permissões de leitura e gravação. A linha do fstab para montar o disco é:

/dev/sdb1 /mnt/drive   ntfs-3g    auto,users,permissions   0   0

Deixe-me dar um exemplo simples, que falha. O seguinte programa python (simple_write.py):

#!/usr/bin/env python2.7

f = open('/mnt/drive/sean/test.txt', 'w')
f.write('Writing in the file')
f.close()

é executado corretamente se executado em um terminal como este:

python2.7 /home/sean/simple_write.py

Se eu, então, criar um pequeno script bash (job_submit.sh) para enviar ao agendador (SGE) assim:

#!/bin/bash
#
#$ -cwd
#$ -j y
#$ -S /bin/bash
python2.7 /home/sean/simple_write.py

e envie de um terminal:

qsub job_submit.sh

Então recebo o seguinte erro (Python):

IOError: [Errno 2] No such file or directory: '/mnt/drive/sean/test.txt'

O problema pode ser resolvido (a) executando simple_write.py diretamente do terminal ou (b) alterando o local de gravação em simple_write.py para algum lugar no disco local, em vez do disco externo (ocorre um erro semelhante para lendo um arquivo / diretório ao invés de escrever). Parece, portanto, que deve haver algum problema com o agendador não jogando bem com a unidade montada, mas estou em uma perda no que tentar em seguida. Qualquer ajuda seria muito apreciada.

    

Answer 1

Agendadores de tarefas de cluster (por exemplo, Sun Grid Engine, HTCondor, SLURM e assim por diante) podem executar trabalhos em algum outro sistema que não seja o host mestre ou de envio de tarefas; Os sistemas de arquivos expostos apenas no host mestre ou de envio de tarefas, portanto, podem estar indisponíveis para os sistemas de execução de tarefas no cluster. O agendador de trabalho pode ter logs ou sinalizadores para indicar em qual sistema um trabalho está sendo executado ou sistemas de arquivos disponíveis podem ser inspecionados enviando um trabalho que executa ls ou df em qualquer sistema em que seja executado (embora, cuidado as tarefas podem bloquear a E / S se houver uma montagem de hardware NFS indisponível, caso em que a tarefa seria bloqueada de acordo com o software de cluster) para determinar se um diretório ou quais sistemas de arquivos estão disponíveis. Se o sistema de arquivos não estiver disponível, ele precisará ser disponibilizado via NFS (ou algum outro sistema de arquivos de rede). Outra opção pode ser fazer com que o software de agendador de tarefas copie os arquivos necessários para o host no qual o trabalho será executado, embora a maneira de fazer isso varie dependendo do agendador de trabalho usado (e, presumivelmente, qualquer arquivo de saída precisaria ser copiado em outro lugar quando o trabalho terminar).

O fato de copiar ou depender de um sistema de arquivos de rede depende da quantidade de dados, uma pequena quantidade de dados pode ser facilmente copiada, enquanto um grande repositório de dados que os trabalhos revisam favoreceria o uso de um sistema de arquivos de rede. Observe também que um grande número de clientes pode facilmente sobrecarregar um servidor NFS; a saída (especialmente a saída temporária) pode precisar ser gravada em um sistema de arquivos local no sistema de execução de tarefas e apenas os resultados gravados no servidor NFS.