2013-05-19 10 views
14

Udało mi się zaskoczyć skryptem powłoki przeznaczonym do uruchamiania co 30 minut w cronie na serwerze Redhat 6. Skrypt powłoki jest po prostu po prostu komendą do uruchomienia skryptu Pythona.scl włącz python27 bash

Pythona rodzimej wersji na serwerze to 2.6.6, ale wersja pythonowa wymagana przez ten konkretny skrypt to python 2.7+. Jestem w stanie łatwo uruchomić to w wierszu poleceń za pomocą polecenia „SCL” (w tym przykładzie zawiera python -V polecenie, aby pokazać zmianę wersji):

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

W tym momencie mogę uruchomić Pythona 2.7 .3 skrypty na linii poleceń bez problemu.

Oto szkopuł.

Po wydaniu polecenia scl enable python27 bash rozpoczyna się nowa sesja powłoki bash, która (ponownie) jest w porządku dla pracy z interaktywnym wierszem poleceń. Ale gdy robimy to wewnątrz skryptu powłoki, natychmiast po uruchomieniu polecenia bash skrypt kończy działanie z powodu nowej sesji.

Oto skrypt powłoki, który zawodzi:

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

To po prostu zatrzymuje się jak tylko natrafi linii 4, ponieważ „bash” wyskakuje go skryptu i do świeżej powłoki bash. Więc nigdy nie widzi rzeczywistego polecenia Pythona, którego potrzebuję do uruchomienia.

Plus, jeśli uruchamiany co 30 minut, to dodaje nowe bash za każdym razem, co jest kolejnym problemem.

Jestem niechętny, aby zaktualizować macierzystą wersję python na serwerze do wersji 2.7.3 właśnie teraz z kilku powodów. Repliki yum redhat nie mają jeszcze python 2.7.3, a ręczna instalacja znajduje się poza systemem aktualizacji yum. Z tego co rozumiem, yum działa na pythonie 2.6.x.

Oto gdzie znalazłem metodę przy użyciu SCL

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

Odpowiedz

22

Robi wszystko w jednym heredoc w środowisku SCL jest najlepszym rozwiązaniem, IMO:

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

Innym sposobem jest uruchomienie tylko drugie polecenie (które jako jedyne używa Pythona) bezpośrednio w środowisku scl:

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

Czy nie jest najłatwiejszy w obsłudze skrypt Pythona? test_python.py:

#!/usr/bin/env python 

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

następnie w crontab:

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

Upewnij się zrobić test_python.py wykonywalny.

Inną opcją jest wywołanie skryptu powłoki wywołującego pytona.test_python.sh:

#/bin/bash 
python test_python.py 

w crontab:

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

Widziałem tylko ten scl rzeczy kiedyś i nie mają łatwego dostępu do systemu z zainstalowanym to. Ale myślę, że to po prostu konfiguracja zmiennej PATH i innych zmiennych środowiskowych w pewien sposób zbliżony do tego, jak są one wykonywane pod virtualenv.

Może zmieniając skrypt mieć połączenie bash subprocess python będzie działać:

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

Wystąpienie python znaleźć na podproces bash „s powłoki powinny być twoje 2.7.x skopiować ... i wszystko inne ustawienia środowiska wykonane przez scl powinny być przez to dziedziczone.

7

source /opt/rh/python27/enable w razie potrzeby.

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

Wyjaśnij swój kod –

2

One liner

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

go używać także z devtoolsets na 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.