web-dev-qa-db-fra.com

scl active python27 bash

J'ai rencontré un problème avec un script Shell destiné à s'exécuter toutes les 30 minutes sous cron sur un serveur Redhat 6. Le script shell n’est en principe qu’une commande permettant d’exécuter un script python. 

La version native python sur le serveur est 2.6.6, mais la version python requise par ce script particulier est python 2.7+. Je peux facilement l'exécuter sur la ligne de commande en utilisant la commande "scl" (cet exemple inclut la commande python -V pour afficher le changement de version):

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

À ce stade, je peux exécuter les scripts python 2.7.3 sur la ligne de commande sans problème.

Voici le problème.

Lorsque vous exécutez la commande scl enable python27 bash, une nouvelle session bash Shell est lancée, ce qui (encore) convient parfaitement pour le travail en ligne de commande interactive. Mais lorsque vous le faites dans un script Shell, dès qu’il exécute la commande bash, le script se ferme à cause de la nouvelle session.

Voici le script shell qui échoue:

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

Il s'arrête simplement dès qu'il arrive à la ligne 4, car "bash" le sort du script et se retrouve dans un nouveau shell bash. Ainsi, il ne voit jamais la commande python proprement dite dont j'ai besoin pour s'exécuter.

De plus, si exécuté toutes les 30 minutes, cela ajouterait un nouveau bash à chaque fois, ce qui est encore un autre problème.

Je suis réticent à mettre à jour la version native de Python sur le serveur vers la version 2.7.3 pour plusieurs raisons. Le référentiel Redhat yum n’a pas encore Python 2.7.3 et une installation manuelle serait en dehors du système de mise à jour yum. D'après ce que j'ai compris, yum fonctionne sous Python 2.6.x.

Voici où j'ai trouvé la méthode d'utilisation de scl

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

bashcronsoftware-collections
17
gerion

Tout faire dans un hérédoc dans l’environnement SCL est la meilleure option, IMO:

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

Une autre méthode consiste à exécuter directement la deuxième commande (la seule qui utilise Python) dans l’environnement scl:

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

scl enable python27 bash active un environnement virtuel python.

Vous pouvez le faire à partir d’un script bash en recherchant simplement le script d’activation de l’environnement virtuel, du package SCL, situé à l’emplacement /opt/rh/python27/enable.

Exemple:

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

N’est-il pas plus simple de simplement utiliser votre script python directement? test_python.py:

#!/usr/bin/env python

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

puis dans votre crontab:

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

Assurez-vous de rendre test_python.py exécutable.

Une autre alternative consiste à appeler un script Shell qui appelle le python. test_python.sh:

#/bin/bash
python test_python.py

dans votre crontab:

2 * * * *   scl python27 enable $HOME/test_python.sh
7
John

Bon mot

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

Je l'utilise aussi avec les devtoolsets sur CentOS 6.x

me@my_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.
3
Dr.Bokko

J'ai déjà vu cette chose scl une fois auparavant et je n'ai pas accès à un système sur lequel il est installé. Mais je pense qu'il ne s'agit que de configurer PATH et certaines autres variables d'environnement d'une manière qui ressemble vaguement à la façon dont elles sont exécutées sous virtualenv.

Peut-être que changer le script pour avoir l'appel bash du sous-processus python fonctionnerait:

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

L'instance de python trouvée dans le sous-processus bash 's Shell devrait être votre copie 2.7.x ... et tous les autres paramètres environnementaux définis par scl devraient en être hérités.

0
Jim Dennis