I'm in trouble with response Values of a phyton script (face_detection).
If I run it directly in the console, everything works pretty well.
If I run it as Part of a shell script, no response apear.
I already checked:
1.) image and scripts are usable by user www-data (at the end it should run as system-request from php). I checked it by sudo -u www-data ..
2.) Also also checked a much simpler command ("ls -l $1"), which brings the expected reponse. So only the python script doesnt work (as sub from bash script).
Now, I have NO Idea what else may be wrong in my code. Any Help would be very apreciated!
Regards Rene´
Some Background info:
Ubuntu 14.4, Kernel 3.13.0-24-generic
PHP 5.5.9-1ubuntu4.26
GNU bash, version 4.3.8(1)-release
face_recognise (https://github.com/ageitgey/face_recognition) V 1.2.3
on terminal:
/usr/local/bin/face_detection /var/www/1545249278.jpg
response is:
/var/www/1545249278.jpg,166,879,701,344 (= correct)
via bash-script:
#!/bin/bash
facePosition=`/bin/bash -c \"/usr/bin/python3 /usr/local/bin/face_detection $1\"`
printf $facePosition
response is: (None/empty = wrong)
I also checked this variations:
facePosition=`/bin/bash -c \"/usr/local/bin/face_detection $1 | /usr/bin/cut -d ',' -f2\"`
facePosition=`/bin/bash -c \"/usr/bin/python3 /usr/local/bin/face_detection $1\"`
facePosition=`env python3 /usr/local/bin/face_detection $1`
Related
I'm puzzled by this problem I'm having on Ubuntu 20.04 where cron is able to run a bash script but the overall outcome is different then when using the shell command.
I've look through all questions I could in here and on Google but couldn't find anyone that had the same problem.
Background:
I'm using Pushgateway to store metrics I'm generating through a bash script, and afterwards it's being imported automatically to Prometheus.
The end goal is to export a list of running processes, their CPU%, Mem% etc, similar to top command.
This is the bash script:
#!/bin/bash
z=$(top -n 1 -bi)
while read -r z
do
var=$var$(awk 'FNR>7{print "cpu_usage{process=\""$12"\", pid=\""$1"\"}", $9z} FNR>7{print "memory_usage{process=\""$12"\", pid=\""$1"\"}", $10z}')
done <<< "$z"
curl -X POST -H "Content-Type: text/plain" --data "$var
" http://localhost:9091/metrics/job/top/instance/machine
I used to have a version that used ps aux but then I found out that it only shows the average CPU% per process.
As you can see, the command I'm running is top -n 1 -bi which gives me a snapshot of active processes and their metrcis.
I'm using awk to format the data, and FNR>7 because I need to ignore the first 7 lines which is the summery presented by top.
The bash scrip is registered on /bin, /usr/bin and /usr/local/bin.
When checking http://localhost:9091/metrics, which is supposed to show me the information gathered, I'm getting this some of information when running the scrip using shell:
cpu_usage{instance="machine",job="top",pid="114468",process="php-fpm74"} 17.6
cpu_usage{instance="machine",job="top",pid="114483",process="php-fpm74"} 11.8
cpu_usage{instance="machine",job="top",pid="126305",process="ffmpeg"} 64.7
And this is the same information when cron is running the same script:
cpu_usage{instance="machine",job="top",pid="114483",process="php-fpm+"} 5
cpu_usage{instance="machine",job="top",pid="126305",process="ffmpeg"} 60
cpu_usage{instance="machine",job="top",pid="128777",process="php"} 15
So, for some reason, when I run it from cron it cuts the process name after 7 places.
I initially though it was related to the FNR>7 but even after changing it to 8 or 9 (and using exec bash to re-register the command) it gives the same results, also when I run it manually it works just fine.
Any help would be appreciated!!
I do this in a script:
read direc <<< $(basename `pwd`)
and I get:
Syntax error: redirection unexpected
in an ubuntu machine
/bin/bash --version
GNU bash, version 4.0.33(1)-release (x86_64-pc-linux-gnu)
while I do not get this error in another suse machine:
/bin/bash --version
GNU bash, version 3.2.39(1)-release (x86_64-suse-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
Why the error?
Does your script reference /bin/bash or /bin/sh in its hash bang line? The default system shell in Ubuntu is dash, not bash, so if you have #!/bin/sh then your script will be using a different shell than you expect. Dash does not have the <<< redirection operator.
Make sure the shebang line is:
#!/bin/bash
or
#!/usr/bin/env bash
And run the script with:
$ ./script.sh
Do not run it with an explicit sh as that will ignore the shebang:
$ sh ./script.sh # Don't do this!
If you're using the following to run your script:
sudo sh ./script.sh
Then you'll want to use the following instead:
sudo bash ./script.sh
The reason for this is that Bash is not the default shell for Ubuntu. So, if you use "sh" then it will just use the default shell; which is actually Dash. This will happen regardless if you have #!/bin/bash at the top of your script. As a result, you will need to explicitly specify to use bash as shown above, and your script should run at expected.
Dash doesn't support redirects the same as Bash.
Docker:
I was getting this problem from my Dockerfile as I had:
RUN bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
However, according to this issue, it was solved:
The exec form makes it possible to avoid shell string munging, and
to RUN commands using a base image that does not contain /bin/sh.
Note
To use a different shell, other than /bin/sh, use the exec form
passing in the desired shell. For example,
RUN ["/bin/bash", "-c", "echo hello"]
Solution:
RUN ["/bin/bash", "-c", "bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)"]
Notice the quotes around each parameter.
You can get the output of that command and put it in a variable. then use heredoc. for example:
nc -l -p 80 <<< "tested like a charm";
can be written like:
nc -l -p 80 <<EOF
tested like a charm
EOF
and like this (this is what you want):
text="tested like a charm"
nc -l -p 80 <<EOF
$text
EOF
Practical example in busybox under docker container:
kasra#ubuntu:~$ docker run --rm -it busybox
/ # nc -l -p 80 <<< "tested like a charm";
sh: syntax error: unexpected redirection
/ # nc -l -p 80 <<EOL
> tested like a charm
> EOL
^Cpunt! => socket listening, no errors. ^Cpunt! is result of CTRL+C signal.
/ # text="tested like a charm"
/ # nc -l -p 80 <<EOF
> $text
> EOF
^Cpunt!
do it the simpler way,
direc=$(basename `pwd`)
Or use the shell
$ direc=${PWD##*/}
Another reason to the error may be if you are running a cron job that updates a subversion working copy and then has attempted to run a versioned script that was in a conflicted state after the update...
On my machine, if I run a script directly, the default is bash.
If I run it with sudo, the default is sh.
That’s why I was hitting this problem when I used sudo.
In my case error is because i have put ">>" twice
mongodump --db=$DB_NAME --collection=$col --out=$BACKUP_LOCATION/$DB_NAME-$BACKUP_DATE >> >> $LOG_PATH
i just correct it as
mongodump --db=$DB_NAME --collection=$col --out=$BACKUP_LOCATION/$DB_NAME-$BACKUP_DATE >> $LOG_PATH
Before running the script, you should check first line of the shell script for the interpreter.
Eg:
if scripts starts with /bin/bash , run the script using the below command
"bash script_name.sh"
if script starts with /bin/sh, run the script using the below command
"sh script_name.sh"
./sample.sh - This will detect the interpreter from the first line of the script and run.
Different Linux distributions having different shells as default.
I stumpled upon a strange behaviour that I can not explain. I tried to narrow down the problem. I have the following test testscript.sh script:
echo before
adb shell ls
echo after
If I run the script with bash -x testscript.sh, everything works as expected and I get the following output:
+ echo before
before
+ adb shell ls
acct
bin
bugreports
...
sdcard
storage
sys
system
ueventd.rc
vendor
+ echo before
before
But if I run the script as piped script with cat testscript.sh | bash -sx, I get the following output:
+ echo before
before
+ adb shell ls
acct
bin
bugreports
...
sdcard
storage
sys
system
ueventd.rc
vendor
The last echo after is not executed, and I can not figure out why. The script is running on an Ubuntu server 18.04. The adb is the one from the official Ubuntu package.
$ adb --version
Android Debug Bridge version 1.0.39
Version 1:8.1.0+r23-5~18.04
Installed as /usr/lib/android-sdk/platform-tools/adb
$ bash --version
GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
Please could someone enlight me, what is happening here.
When you run a script with bash scriptname, standard input of all the commands it runs is still connected to the terminal. So adb will read its standard input from the terminal.
When you redirect the input of bash, this redirection is inherited by adb. Unless you use the -n option to adb shell, it will read additional input from standard input and send it to the remote system as possible input for the command you run (it doesn't know that ls doesn't read standard input).
Change it to
adb shell -n ls
I have 2 scripts that I'm testing to automate starting services on my server however they behave weirdly.
The first script is
#!/bin/sh
screen -dmS Test_Screen
sleep 1
sudo sh cd.sh
echo "finished"
Which runs perfectly however the script it runs does not and is as follows
#!/bin/sh
screen -S Test_Screen -X stuff "cd /home/Test"
sleep 1
screen -S Test_Screen -X eval "stuff \015"
sleep 1
echo "Complete"
The second script will run perfect if I run it from command line and will CD into the directory within the screen. However, if it runs from the first script it Will Not CD into the correct directory within the screen, but it will still print "Complete".
I'm Using CENTOS 6.7 and the latest version of GNU screen
Any Ideas?
This seems to be a problem with session nesting.
In your first script you create a session named Test_Screen.
In your second script the -S parameter tells screen to create a session of the same name. This might cause screen to exit and not cd into the correct directory.
You could move the cd command in front of the sudo sh cd.sh and remove those screen calls from the second script leaving only
stuff \015
echo "Complete"
Using the correct screenflags should also work.
#!/bin/sh
screen -dr Test_Screen -X stuff "cd /home/Test"
sleep 1
screen -dr Test_Screen -X eval "stuff \015"
sleep 1
echo "Complete"
For a more modern alternative to screen, have a look at tmux.
Ok so this turned out really weird. After posting i tried a couple of things on a centos 6.7 hyper V test environment and got the exact same issue. However, later in the day we ended up changing service provider and upgrading to centos 7 in the process. I am not sure why but since the update the script now runs perfectly and i was able to actually merge the two scripts into one in order to make it more efficient. If anyone knows why the update fixed it feel free to let me know.
So i have a script for waking up my computer using rtc... The script manually works fine but when i am trying to run it through crontab -e it doesnt work. I am not very familiar with cron so maby i am doing something wrong.
at this time i use the command:
#reboot /nikos/script/auto.sh
just to try and see if it is working...a tried some other ways(using path and some others but nothing work)
THe code of the script
#!/bin/bash
sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"
sh -c "echo `date '+%s' -d '+ 420 minutes'` > /sys/class/rtc/rtc0/wakealarm"
any help is apreciated
EDIT:
in order to see if it worked i run:
cat /proc/driver/rtc
and i see that it rtc alarm is not enabled
I see one thing right off. You need to provide absolute paths to /bin/sh, /bin/echo and /bin/date
Putting absolute paths in scripts executed in cron solves most problems. If your scripts run fine on the command line but not in cron that is usually the culprit.
/bin/sh -c "/bin/echo 0 > /sys/class/rtc/rtc0/wakealarm"
/bin/sh -c "/bin/echo /bin/date '+%s' -d '+ 420 minutes' > /sys/class/rtc/rtc0/wakealarm"
Answers to another post at stackexchange also makes mention of cron having issues with #reboot scripts for many reasons. Check here: https://unix.stackexchange.com/questions/109804/crontabs-reboot-only-works-for-root
It may be worth your while to run it by adding it to a bootup script such as /etc/rc.d/rc.local instead of using cron. You will still have best results providing absolute paths to commands to make sure they are accessible.
Also: test if #reboot is working properly on your system. Not all versions of cron execute that properly. Add this script to test: #reboot /bin/echo "#reboot works" > /tmp/reboot_test
If your target directory is not available at boot time by the time your reboot script starts that will also cause a problem.