/ usr / bin / env: php: ऐसी कोई फ़ाइल या निर्देशिका नहीं


9

मैं अपने ऐप की तैनाती के लिए .sh स्क्रिप्ट का उपयोग करना चाहता हूं। वह स्क्रिप्ट मेरे होम सर्वर (Ubuntu 15.10 सर्वर) पर है, जिसे निष्पादन योग्य के रूप में चिह्नित किया गया है। इस स्क्रिप्ट तक पहुंच ssh के माध्यम से की जाती है, इस ट्यूटोरियल का उपयोग करके , मैंने ssh लॉगिन सेट किया है, जो उस स्क्रिप्ट को चलाता है। इसलिए मूल रूप से मैं सिर्फ कॉल करता हूं ssh deployer@XXX.com someArgumentsऔर यह मेरी स्क्रिप्ट someArgumentsको मापदंडों के रूप में चलाता है । उपयोगकर्ता के deployerपास uid = 0 है, इसलिए इसका मूल रूप से root(इसे भविष्य में बदल दिया जाएगा, मैंने इसे केवल अनुमतियों की समस्याओं को समाप्त करने के लिए सेट किया है जब तक कि यह ठीक काम न करे)।

और यहां वह जगह है जहां चीजें मुश्किल हो जाती हैं। /usr/bin/env: php: No such file or directoryकमांड पर स्क्रिप्ट रिपोर्ट /bin/composer install( संगीतकार का उपयोग करके )। चीजें और अधिक अजीब हैं जितना अधिक मैं उस स्क्रिप्ट को देखता हूं। इस लाइन से पहले, वहाँ भी कहा जाता है /bin/composer self-updateऔर /bin/composer -V, जो दोनों सही ढंग से चलता है और सही आउटपुट प्रदर्शित करता है।

मैंने निम्नलिखित चीजों की जाँच की है:

  • /usr/bin/env php -vसही PHP संस्करण प्रदर्शित करता है (जैसा कि /usr/bin/php -v)
  • whereis php प्रदर्शित करता है php: /usr/bin/php /usr/local/bin/php /usr/share/man/man1/php.1.gz
  • php5-cli पैकेज स्थापित और नवीनतम संस्करण है
  • $PATH शामिल /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  • which env प्रदर्शित करता है /usr/bin/env

मैंने निम्नलिखित चीजों को भी आजमाया है:

  • स्क्रिप्ट को bash deploy.shरूट के तहत सीधे चलाना (चूंकि यह उस उपयोगकर्ता के समान है) - त्रुटियों के बिना पूरी तरह से काम करता है
  • फेलिंग कमांड सीधे - बिना त्रुटियों के भी पूरी तरह से चल रहा है

तो यह मुझे बहुत विशिष्ट मामला लगता है, यह कमांड काम क्यों नहीं करता है। मैंने इसे डिबग करने के 12 घंटे बिताए और मैं यहां विचारों से बाहर हूं।

PS: इसी तरह की त्रुटि ( /usr/bin/env: node: No such file or directory) तब होती है जब bower install( बोवर का उपयोग करते हुए ) होती है , लेकिन नहीं चलने पर npm install( एनपीएम का उपयोग करके )।


के sh deployबजाय bash deploy(शायद कुछ बैशिज़्म) चलाएं। आपने " निम्नलिखित चीजों " की जांच कैसे की ? मैं उन्हें स्क्रिप्ट में जांचने की सलाह देता हूं, ताकि आप एनवीएस के अंतिम ओवरराइड और स्वच्छता की खोज कर सकें।
जियाकोमो कैटेनज़ज़ी

" निम्नलिखित बातों " के बारे में : मैंने उन्हें तैनाती की शुरुआत के लिए जोड़ा। एस स्क्रिप्ट और वे इन चीजों को आउटपुट करते हैं जिन्हें मैंने सवाल करने के लिए नीचे रखा था। समान आउटपुट तब होता है जब मैं उन्हें अकेले चलाता हूं, हालांकि।
टॉम ब्‍लैटनी

sh deployऔर bash deployदोनों एक ही परिणाम देता है
Tomáš Blatný

कृपया यहां वह लाइन दिखाएं। मैं आपको सलाह देता हूं कि आप कॉलिंग / usr / bin / env के क्षण में पर्यावरण चर की जांच करने के लिए आउटपुट के साथ अपनी स्क्रिप्ट में इस लाइन पर अपनी php कमांड को फाइल करें:/usr/bin/env > environment.txt
Oracle Bolden

जवाबों:


6

सुनिश्चित करें कि लाइन एंडिंग और / या अदृश्य स्थान समस्या पैदा नहीं कर रहे हैं।

स्क्रिप्ट की पहली पंक्ति में रिक्त स्थान निकालें और नए को सम्मिलित करें, यह सुनिश्चित करते हुए कि अंतरिक्ष को दबाते समय CTRL को न रखें।

यह भी सुनिश्चित करें कि आपके पास डॉस लाइन एंडिंग (CR + LF) नहीं है। देखें /programming/82726/convert-dos-line-endings-to-linux-line-endings-in-vim जानकारी के लिए।


मैं IDE का उपयोग कर रहा हूं, जो स्वतः ही (और धर्मान्तरित) CR + LF को LF में जाँचता है, BOM को हटाता है और श्वेत वर्णों की परवाह करता है, लेकिन मैंने इसे डबल-चेक किया, और यह ठीक दिखाई देता है (फिर भी काम नहीं कर रहा है)। वैसे भी धन्यवाद
Tomáš Blatný

4

सबसे आसान तरीका .... स्क्रिप्ट के रूप में उपयोगकर्ता के शेल को बदलें।

/ Etc / पासवर्ड

Before:
deploy:x:0:0:,,,:/root:/bin/bash

After:
deploy:x:0:0:,,,:/root:/scripts/deploy.sh

उदाहरण स्क्रिप्ट (सुनिश्चित करें कि निष्पादित बिट सेट है chmod + x)

/scripts/deploy.sh

#!/bin/bash 
PATH=$PATH:/moo etc...
moo.sh

नमूना हर समय काम करता है! आपको किसी भी env चर का समस्या निवारण / डीबग करने के लिए स्क्रिप्ट का उपयोग करने में सक्षम होना चाहिए, जिसे आप महसूस कर सकते हैं कि आप परेशान हैं आदि ... साथ ही ssh में दिए जा रहे हैंडलिंग तर्क भी काम करेंगे।

नोट: किसी भी स्क्रिप्ट, निष्पादन योग्य, आदि के लिए पथों को हमेशा पूर्ण रूप से पूरा करने के लिए इसका सबसे अच्छा अभ्यास .. ऊपर सिर्फ एक उदाहरण है जो डिफ़ॉल्ट पथ को moo.sh फ़ोल्डर में कॉल करने की अनुमति देता है;)

यह आसान था .. पोस्टिंग के लिए धन्यवाद ..

संदर्भ: / आदि / पासवार्ड प्रारूप


अच्छा जवाब है, लेकिन मैं वास्तव में कभी भी सर्वर पर सीधे उपयोगकर्ता का उपयोग नहीं करता हूं, मैं हमेशा sshसर्वर पर रहता हूं , और लेन में authorized_keys, स्क्रिप्ट को कॉल किया जाता है और फिर कनेक्शन समाप्त होता है। authorized_keysइस कार्य को करने के लिए मुझे कैसे संशोधित करना चाहिए?
टॉम ब्‍लैटनी

यह उसी तरह काम करना चाहिए। आप कुंजी के माध्यम से प्रमाणित करेंगे और जब तक शेल दूरस्थ खाते के लिए स्क्रिप्ट में दूरस्थ सर्वर / etc / passwd फ़ाइल के भीतर सेट हो जाता है, तो स्क्रिप्ट निष्पादित होगी। मैं शीघ्र ही अपनी पोस्ट में एक स्क्रीनशॉट जोड़ूंगा।
NotAdmin डेव

1
@Dave अपनी पुस्तक के लिए इंतजार नहीं कर सकता
Bürgi

आपके उत्तर के लिए धन्यवाद, इसने मेरी समस्या को हल नहीं किया, लेकिन मेरे लिए सबसे दिलचस्प था और वास्तव में मेरे पास अन्य समस्याओं का समाधान था। तुम्हें इनाम दिया, फिर से धन्यवाद
टॉम Blatný

4

envआदेश एक उपयोगकर्ता के माध्यम से दिखाई देंगी $PATHदिए गए नाम के पहले निष्पादन योग्य खोजने के लिए। इसलिए, उपयोगकर्ता द्वारा चलाए जा रहे किसी भी निर्देशिका में /usr/bin/env phpएक निष्पादन योग्य फ़ाइल को बुलाया जाएगा।php$PATH

आपके मामले में, यह लगभग निश्चित रूप से है क्योंकि जब एक कमांड पर चल रहा है ssh, तो आप एक पूर्ण शेल शुरू नहीं करते हैं और वास्तव में आपके शेल की आरंभीकरण फ़ाइलों को नहीं पढ़ते हैं। आप इस आदेश को चलाकर इसकी जांच कर सकते हैं (एकल उद्धरण नोट करें):

ssh deployer@XXX.com 'echo $PATH'

और आउटपुट की तुलना अगर आपको मिलती है तो आप ssh deployer@XXX.comऔर फिर चलाएं echo $PATH। मेरे सिस्टम पर। उदाहरण के लिए:

$ echo $PATH
/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:

$ ssh localhost 'echo $PATH'
/usr/bin:/bin:/usr/sbin:/sbin

इसलिए, $PATHआपकी स्क्रिप्ट की पहुंच उस समय तक होती ssh deployer@XXX.comहै जब आप इसे टेस्ट करने के लिए लॉग इन करते हैं।

किसी भी मामले में, सरल उपाय इसके बजाय दुभाषिया के लिए पूर्ण पथ का उपयोग करना है env। दोनों envऔर पूर्ण पथ के अपने लाभ और कमियां हैं लेकिन, इस मामले में, पथ सुरक्षित है:

#!/usr/bin/php

ITYM " ध्यान दें एकल उद्धरण" नहीं " नहीं "।
dave_thompson_085

@ dave_thompson_085 वास्तव में मैंने किया, धन्यवाद।
टेराडन

मैं वास्तव में हर जगह पूर्ण पथों का उपयोग कर रहा हूं, जैसा कि मैंने अपने प्रश्न में उल्लेख किया है, त्रुटि कमांड के अंदर बताई composer installगई है, जिसे मैं स्पष्ट रूप से संशोधित नहीं कर सकता। यह $PATHभी ठीक है, जैसा कि मैंने अपने प्रश्न में भी उल्लेख किया है, मैंने सभी चीजों को स्क्रिप्ट में जोड़कर और ssh लॉगिन द्वारा दूरस्थ रूप से चलाने की जाँच की। इसके अलावा, मैं ssh deployer@XXX.com 'echo $PATH'आपके द्वारा बताए अनुसार जाँच नहीं कर सकता , क्योंकि मेरा ssh लॉगिन केवल एक स्क्रिप्ट तक ही सीमित है, लेकिन मैंने उस स्क्रिप्ट में $ PATH जोड़ते समय इसे चेक किया था (ऊपर बताए गए) वैसे भी, आपके उत्तर के लिए धन्यवाद, और स्वीकार + 1 मुझे envबात समझाने के लिए
टॉम ब्लटनी

@ TomášBlatný अच्छी तरह से, आप कहीं न कहीं env का उपयोग कर रहे हैं, या आप उस त्रुटि को नहीं देख रहे हैं। मैं संगीतकार को नहीं जानता लेकिन आपको शायद इसके मार्ग में निर्देशिका के लिए php निष्पादन योग्य कॉपी या लिंक करना होगा। इस तरह की चीज़ को डिबग करना कठिन होता है क्योंकि प्रत्येक चीज़ बहुत सारी होती है जो दूसरे पर निर्भर करती है।
टेराडन

यह सच है, envवास्तव में संगीतकार के अंदर कहा जाता है। लेकिन यह समस्या को हल नहीं करता है, क्यों कुछ संगीतकार कॉल पास करते हैं, और कुछ नहीं। हालाँकि मैं इसके कोड को देखकर इसकी जांच करूंगा। आपके समय के लिए धन्यवाद
टॉम ब्लाट्न

2

क्या यह संभव है कि bashइसकी हैश तालिका में रीसेट की आवश्यकता है?

यदि ऐसा है, तो आप hash -rअपनी स्क्रिप्ट में कहीं और जोड़ने का प्रयास कर सकते हैं , जो शेल को $PATHहैश टेबल से (संभवतः पुरानी) जानकारी पर भरोसा करने के बजाय फिर से देखने के लिए मजबूर करता है ।

जब जरूरत हो, hashतो शेल को -pविकल्प का उपयोग करके गैर-मानक स्थानों में स्थापित निष्पादन योग्य पथों को याद रखने में सक्षम कर सकता है, या -dविकल्प के साथ पथों को भूल सकता है।

सूत्रों का कहना है:

https://unix.stackexchange.com/a/86017/121251
https://stackoverflow.com/a/22543353/2146843


यह मेरे लिए समस्या का हल नहीं है, हालांकि इसका अच्छा ज्ञान है, इसलिए मैंने आपको एक +1 जोड़ा
Tomáš Blatný

1

ऐसा लगता है कि शायद आपको अपने पथ पर php जोड़ने की आवश्यकता है। प्रयत्न:

vim ~/.bashrc
PATH=$PATH:/usr/local/bin/php
export PATH

आप यह भी जाँचना चाह सकते हैं कि आपका php यह सुनिश्चित करने के लिए रहता है कि वहाँ का रास्ता सही है। प्रयत्न:

which php

वैसे यह समस्या नहीं है, क्योंकि php -vआउटपुट PHP संस्करण को सही करता है और composer --versionसंगीतकार संस्करण को आउटपुट करता है। जैसा कि मैंने कहा, समस्या केवल एक कमांड में है।
टॉम ब्‍लैटनी

1

यह स्पष्ट है कि आपके पास एक पथ समस्या है क्योंकि आपकी तैनाती स्क्रिप्ट उन चीजों को नहीं पा सकती है जो निश्चित रूप से पथ पर हैं जब आप एक सामान्य ssh लॉगिन करते हैं।

पहली बात यह है कि आपके पास एक पैठ मुद्दा है कि envकम से कम या कम से कम उत्पादन लॉग करने के लिए अपनी तैनाती स्क्रिप्ट को अपडेट करें echo $PATH। मैं अनुमान लगा रहा हूं कि जिस तरह से आपकी तैनाती स्क्रिप्ट कहलाती है, $ PATH सेट नहीं है जैसा कि आप उम्मीद करेंगे। यह डिबग आउटपुट मेरे सिद्धांत की पुष्टि / खंडन करेगा।

मैंने आपके द्वारा अनुसरण किए गए ट्यूटोरियल को देखा। यदि आपकी स्क्रिप्ट सही शेल द्वारा चलाई जाती है, तो आपको पहले ही यह सुनिश्चित कर लेना command=चाहिए command="/bin/sh /path/to/your/script..."कि क्या आप पहले से ही अपडेट नहीं हैं।

यदि आपके पास एक PATH समस्या है, तो एक त्वरित / गंदा फिक्स सिर्फ आपकी तैनाती स्क्रिप्ट की शुरुआत में स्पष्ट रूप से PATH सेट करने के लिए है।

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

विस्तृत विवरण और आगे के विकल्प ...

लिनक्स पर जब कमांड चलाए जाते हैं तो वे अपनी मूल प्रक्रिया के वातावरण को विरासत में देते हैं।

जब आप SSH के माध्यम से एक सामान्य उपयोगकर्ता के रूप में लॉग इन करते हैं तो कुछ चीजें होती हैं (जैसे कि रनिंग / etc / bashrc / etc / profile ~ / .bash_profile ~ / .bashrc आदि)। उस बिंदु पर, आपने export PATH="$PATH:~/mybin"उन स्क्रिप्ट्स की तरह काम करके अपनी प्रक्रिया के वातावरण को अपडेट किया होगा । अब आपके द्वारा चलाए जा रहे भविष्य की कोई भी प्रक्रिया आपके वर्तमान परिवेश को विरासत में देगी।

लॉगिन शेल प्राप्त करने के बजाय कमांड चलाने का अर्थ है कि कमांड ssh डेमॉन द्वारा चलाया जाता है और ssh डेमन प्रक्रिया के वातावरण को विरासत में मिलेगा ... जो कि आपके वातावरण से लॉग इन के रूप में संभवतः अलग है।

अधिकृत कुंजी के लिए मैन पेज में प्रमाणीकरण के बाद क्या होता है। पर्यावरण के बारे में:

  1. फ़ाइल को पढ़ता है ~ / .ssh / पर्यावरण, यदि यह मौजूद है, और उपयोगकर्ताओं को अपने वातावरण को बदलने की अनुमति है। Sshd_config (5) में PermitUserEnvironment का विकल्प देखें।

तो प्रक्रिया के लिए पर्यावरण को कॉन्फ़िगर करने का उपयुक्त स्थान वह है ~/.ssh/environmentजहां ~उपयोगकर्ता के लिए होम डायरेक्टरी है जो कमांड चलाने के लिए प्रमाणित है। आपको यह सुनिश्चित करने के लिए भी अपने sshd_config की जांच करने की आवश्यकता है कि PermitUserEnvironment को अनुमति है।

~/.ssh/environment प्रारूप निश्चित रूप से मैन पेज में भी निर्दिष्ट है।

         This file is read into the environment at login (if it exists).
         It can only contain empty lines, comment lines (that start with
         '#'), and assignment lines of the form name=value.  The file
         should be writable only by the user; it need not be readable by
         directory becomes accessible.  This file should be writable only
         by the user, and need not be readable by anyone else.

उपर्युक्त विधि का उपयोग किए बिना पर्यावरण को निर्दिष्ट करने का एक वैकल्पिक तरीका environment="NAME=value"अधिकृत_की फाइल में विकल्प का उपयोग करना है। विवरण के लिए उपरोक्त मैन पेज देखें।


के बारे में Without knowing exactly how you have setup your deploy script to run: भीख मांगने के संबंध में मेरे सवाल में, एक कड़ी है, मैंने इसे कैसे सेट किया (उपयोग कर रहा है ~/.ssh/authorized_keys। अपडेट कमांड के साथ टिप के लिए धन्यवाद, मैंने इसे आजमाया, लेकिन बिना किसी अंतर के दुर्भाग्यपूर्ण। मैं हालांकि इस बात की जांच करूंगा और अलग-अलग खोल की कोशिश करूंगा। कृपया उस विचार के लिए एक +1 स्वीकार करें।
Tomáš Blatný

क्या आपने मौजूदा $ PATH को प्रिंट करने के लिए अपनी तैनाती स्क्रिप्ट को अपडेट करने की कोशिश की? क्या आप परिणाम पोस्ट कर सकते हैं? यदि यह आपकी अपेक्षा के अनुरूप नहीं है, तो आप केवल पैठ को स्पष्ट रूप से स्थापित करने का प्रयास कर सकते हैं जैसा कि मैंने आपकी तैनाती स्क्रिप्ट की शुरुआत में सुझाव दिया था।
मटका
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.