2013-05-19 11 views
14

Ho avuto un problema con uno script di shell che doveva essere eseguito ogni 30 minuti su cron su un server Redhat 6. Lo script di shell è fondamentalmente solo un comando per eseguire uno script python.scl enable python27 bash

La versione nativa python sul server è 2.6.6 ma la versione python richiesta da questo particolare script è python 2.7+. Sono in grado di eseguire facilmente questo sulla riga di comando utilizzando il comando "SCL" (questo esempio include il pitone -V comando per visualizzare il cambiamento di versione):

$ python -V 
Python 2.6.6 
$ scl enable python27 bash 
$ python -V 
Python 2.7.3 

A questo punto posso correre il pitone 2.7 .3 script sulla riga di comando nessun problema.

Ecco l'intoppo.

Quando si invia il comando scl enable python27 bash, viene avviata una nuova sessione di shell bash che (ancora) va bene per il lavoro di comando interattivo. Ma quando si fa questo all'interno di uno script di shell, non appena viene eseguito il comando bash, lo script termina a causa della nuova sessione.

Ecco lo script di shell che sta fallendo:

#!/bin/bash 
cd /var/www/python/scripts/ 
scl enable python27 bash 
python runAllUpserts.py >/dev/null 2>&1 

semplicemente ferma non appena colpisce la linea 4, perché "bash" salta fuori dalla sceneggiatura e in una shell bash fresca. Quindi non vede mai l'effettivo comando python di cui ho bisogno per funzionare.

Inoltre, se eseguito ogni 30 minuti, questo aggiungerebbe una nuova bash ogni volta che è un altro problema.

Sono riluttante ad aggiornare la versione nativa di Python sul server alla 2.7.3 in questo momento per diversi motivi. I repository Redhat yum non hanno ancora python 2.7.3 e un'installazione manuale sarebbe al di fuori del sistema di aggiornamento yum. Da quello che ho capito, yum stesso gira su Python 2.6.x.

Ecco dove ho trovato il metodo per l'utilizzo SCL

http://developerblog.redhat.com/2013/02/14/setting-up-django-and-python-2-7-on-red-hat-enterprise-6-the-easy-way/

risposta

22

Fare tutto in uno heredoc nell'ambiente SCL è l'opzione migliore, IMO:

scl enable python27 - << \EOF 
cd /var/www/python/scripts/ 
python runAllUpserts.py >/dev/null 2>&1 
EOF 

Un altro modo è quello di eseguire solo il secondo comando (che è l'unico che usa Python) direttamente in ambiente scl:

cd /var/www/python/scripts/ 
scl enable python27 "python runAllUpserts.py >/dev/null 2>&1" 
6

Non è il più semplice per il solo script Python direttamente? test_python.py:

#!/usr/bin/env python 

import sys 
f = open('/tmp/pytest.log','w+') 
f.write(sys.version) 
f.write('\n') 
f.close() 

poi nel vostro crontab:

2 * * * * scl python27 enable $HOME/test_python.py 

assicuratevi di fare test_python.py eseguibile.

Un'altra alternativa è chiamare uno script di shell che chiama il python.test_python.sh:

#/bin/bash 
python test_python.py 

nel vostro crontab:

2 * * * * scl python27 enable $HOME/test_python.sh 
0

ho solo visto questa roba scl una volta prima e non hanno accesso immediato a un sistema con installato. Ma penso che si stia semplicemente impostando PATH e alcune altre variabili di ambiente in un modo che è vagamente simile a come sono fatte sotto virtualenv.

Forse cambiando lo script per avere la chiamata bash sottoprocesso python avrebbe funzionato:

#!/bin/bash 
cd /var/www/python/scripts/ 
(scl enable python27 bash -c "python runAllUpserts.py") >/dev/null 2>&1 

L'istanza di python trovato sul sottoprocesso bash s' shell dovrebbe essere la vostra 2.7.x copiare ... e tutto il altre impostazioni ambientali effettuate da scl dovrebbero essere ereditate in tal modo.

7

source /opt/rh/python27/enable se necessario.

#!/bin/bash 
cd /var/www/python/scripts/ 
source /opt/rh/python27/enable 
python runAllUpserts.py >/dev/null 2>&1 
+1

Spiega il codice –

2

uno di linea

scl enable python27 'python runAllUpserts.py >/dev/null 2>&1' 

lo uso anche con i devtoolsets sulla 6.x CentOS

[email protected]_host:~/tmp# scl enable devtoolset-1.1 'gcc --version' 
gcc (GCC) 4.7.2 20121015 (Red Hat 4.7.2-5) 
Copyright (C) 2012 Free Software Foundation, Inc. 
This is free software; see the source for copying conditions. There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.