Dlaczego w tym miejscu jest uruchamiany podproces OSError?

Napisałem swój własny moduł, głównie do obsługi pola plików dla witryny django. Po zabawieniu się z niektórymi rzeczami związanymi z mod_wsgi (rozwiązanymi przez aktualizację do wersji 3.3), mam uruchomiony mój kod. Zaraz po wszystkich niezbędnych importu, przed określeniem żadnych klas lub funkcje, przetestować za dostępność Sox, a audiocommandlinetool niezbędny do niektórych z moich modułów funkcji:Dlaczego w tym miejscu jest uruchamiany podproces OSError?

sox = 'path/to/sox' 
test=subprocess.Popen([sox,'-h'], shell=False, stdout=subprocess.PIPE, stderr=subprocess.PIPE) 
error=test.communicate()[1] 
if error: 
    raise EnvironmentError((1,'Sox not installed properly'),)

To działało w porządku. Teraz mam zaktualizowane ubuntu od 8.04 do 10.04 oraz kod przerywa na linii wywołaniu subprocess.Popen, rzucając się następujący komunikat o błędzie:

File "/usr/lib/python2.6/subprocess.py", line 1139, in _execute_child 
    raise child_exception 
OSError: [Errno 8] Exec format error

już wyglądał praw wykonawczych SOx, nie mam innego pomysł, gdzie szukać rozwiązania tego. Czy prawa wykonywania podprocesów mogą być ograniczone? Jakieś wskazówki, co tu się może dziać?

Źródło

2011-03-17 marue

Co się stanie, jeśli uruchomisz podproces z opcją 'shell = True' i wykonasz aplikację tak, jak zwykle w konsoli, na przykład' test = subprocess.Popen ("/ path/to/sox -h", shell = True, stdout = subprocess.PIPE, stderr = subprocess.PIPE) "ten sam wynik? – Anders

Hmmm, to powoduje, że linia 'raise EnvironmentError ((1, 'Sox nie jest poprawnie zainstalowana'),)' jest wykonywana, a EnvironmentError jest podnoszony. Dzieje się tak z developserver i apache/mod_wsgi. Sox można uruchomić z wiersza poleceń bez żadnych problemów, więc nie mogę sobie wyobrazić, że zgubiłem flagę jądra, jak zasugerował samurailawngnome. I nie może to być również przywilej użytkownika, zacząłem sox jako zwykły użytkownik, su i dane www ... – marue

Instrukcja 'raise' powinna pokazać, co zostało przechwycone w' error'. Może to być prawidłowa wiadomość o błędzie sox. – Apalala

Podpowiedź Apali rozwiązała problem. Upewnij się, że wypróbujesz różne wersje soxu, jeśli to samo stanie się ponownie. Nawet jeśli sox działa na linii poleceń, może powodować problemy z podprocesorem.

Źródło

2012-03-11 17:05:56 marue

Wpadłem na ten Q/A z podobnym problemem dzisiaj. "Shell = True" pracował dla mnie. Miało to związek z moją LD_LIBRARY_PATH i plikiem wykonywalnym próbującym połączyć różne .so, niż się spodziewałem. Dodaję tutaj komentarz w nadziei, że pomoże to komuś innemu. –

Spróbuj wykonać polecenie sox, jako ten sam użytkownik, który jest uruchomiony w procesie django wsgi.

Możliwe, że plik binarny nie jest wykonywany przez tego użytkownika lub że po aktualizacji z 8.04 na 10.04, utraciłeś flagę jądra zezwalającą na wykonanie pewnych typów binarnych.

Źródło

2011-03-17 21:12:13 samurailawngnome

Zalogowany jako dane www, zgodnie z konfiguracją witryny dla demona wsgi. Wykonywanie sox z linii poleceń działało dobrze. Czy to właśnie podejrzewasz? – marue

Jeśli korzystasz z systemu Linux i otrzymujesz komunikat "OSError: [Errno 8] Błąd formatu Exec" - sprawdź, czy kernel i plik wykonywalny są dla tej samej platformy - 32-bitowe i 64-bitowe. uname -a i file <executable path> załatwią sprawę. To było moje rozwiązanie (i ta strona jest pierwszym trafieniem dla tego błędu).

Źródło

2012-03-08 15:56:54 fsckin

Czy jest to możliwe do 32-bitowego procesu do exec() a 64 bitów jeden? – lvella

Jestem pewien, że tak. – fsckin

Dlaczego w tym miejscu jest uruchamiany podproces OSError?

Odpowiedz

Powiązane problemy