Hello I need help trying to figure out how to run a shell script in startup. I know that the magicmirror.sh script works and I know it is in the right path. When I reboot my raspberry pi it does not run the script. I have added the line of code to the end of the crontab using sudo crontab -e. The code is as follows.
#reboot sleep 60 && /home/pi/magicmirror.sh
The problem could be the way you call commands in your script.
As the crontab runs from e very minimal shell, not all environment vars get loaded.
So maybe the $PATH var is missing / not fully loaded, so some binary you call from inside the script is not found.
I guess you script starts with #!/bin/bash. If my guess is correct either try to start te script with #!/bin/env /bin/bash (this means "start bash with a full environment") or replace all calls/commands in you script with their full path. e.g. /usr/local/bin/myprog dosomething instead of myprog dosomething.
EDIT:
As #shv mentioned this could ALSO be a problem of permissions. But maybe in a different kind of way. If you run sudo crontab -e you are editing the crontab of root, not of your pi user. This has 2 effects:
you script is run in the environment of root. Sometimes some configurations enable you to do things differently than the root user. I am by no means a Raspberry pi expert, but it could be that your magic mirror accesses some GPIO pins. I can imagine that, although having more permissions to GPIO, root has to interact in a different way with GPIO than your pi user. (wild guess)
This is actually a security risk. Your pi user can edit the magicmirror.sh at will and write anything it it. So for example, someone having access to that pi user (either because he "hacked" the system, or is just someone you gave access to it) could write e.g. rm -rf --no-preserve-root / and just rebooting the device, to clean the filesystem. And you would not want to to that, do you?
To fix this you can either just edit you own crontab with crontab -e (without sudo) or put that script somewhere only root can access (if you need the root permissions) e.g. /root/magicmirror.sh
I think it's an issue with permissions.
try use crontab -e without sudo.
Related
So I have this issue on archlinux with crontab. I have a python script which when run opens a webcam with detection AI. I have tried it outside of the crontab several times and it runs perfectly but when I try to schedule it and run with crontab I can't see webcam opening. I am guessing it might be because of the privileges of the crontab or maybe some dependencies. Any help is appreciated. Thanks all in advance.
When you run from shell, e.g. bash, it calls .bash_profile, which you might have setup some environment variables. Therefore, your webcam program work. To proof my point, rename the .bash_profile temporary to other filename, and it should fail in shell prompt like crontab as well.
If above is valid, then you need to add necessary environment variables into your program, e.g. shell script. This is a standard practice for all programs triggered by UNIX crontab
I have a script foo.sh located in /home/pi/Documents/Python directory. Purpose of this shell script is to run python script which needs root priviledges as it must reset usb device.
The script is as follows:
#!/bin/sh
export PATH="$PATH:/home/pi/.local/lib/python3.7"
python3 /home/pi/Documents/Python/foo.py
When I run the foo.py from Midnight Commander (setting a cursor on the file and pressing enter) it works, it exports the path correctly and the python script fails as it does not have enough priviledges to reset usb device.
I have actually made this script to run python script under root, but the root needs set a path to used module first.
However when I run
sudo foo.sh
I receive an answer:
sudo: foo.sh: command not found
I have checked the permissions and the foo.sh file has -rwxr-xr-x
sudo python3
typed in terminal also works correctly and opens python interpreter.
What is the problem that causes wrong behaviour under sudo?
I might be mistaken (I don't have a Linux Machine at hand atm, so I cannot verify), but if I recall correctly the user_home is part of the PATH variable exported for that user.
When you use the command sudo you are acting on the behalf of root which has got a different user_home than yours (== the current user), therefore your script is not found in any of the directories listed in the active PATH (the one of root because you are using the sudo command).
However, it should be possible to run successfully the following command:
$ sudo ./foo.sh
I hope this might shed some light.
Unless foo.sh is in a directory shown referenced by the PATH environmental variable, the environment will not recognise the command and hence the error
If you are in the directory with the foo.sh script, execute it with:
sudo ./foo.sh
If you are in a different directory, execute with:
sudo /pathtosh/foo.sh
I wan to run a python script every time my computer boots up. For this I have seen quiet some tutorials that suggest to do
crontab -e
#reboot python3 /home/user/Desktop/my_script.py
It would be nice if I can also start is after lets say 30 seconds, so I do
#reboot sleep 30; python3 /home/user/Desktop/my_script.py
I have tried it on my computer as well as on a Raspberry Pi, but it doesn't seem to work. To check I make the python script make a graph and save it on desktop, but it doesn't do so. However , it runs fine if I run it manually from terminal. Can someone help what I am missing here.
Thanks
Can you try using /etc/rc.local file ?
Add the command inside the file with full path (example: /usr/bin/python ...) and mark the file executable.
chmod +x /etc/rc.local
Note: Make sure to use full path to the executables, else export PATH variable in the /etc/rc.local file.
I would like my root-requiring bash script to be run from IntelliJ/WebStorm, asking me for the root password when I run it. Having my root password hardcoded in the script is a bad idea of course.
IntelliJ/WebStorm actually has a $Prompt$ macro for reasons like this, which prompts you and uses your input as a value.
So I tried using $Prompt$ along with echo YOURPASSWORD | sudo -S yourcommand as described in use-sudo-with-password-as-parameter.
Then I pass passwd & script to run to a sudorun.sh script echo -e $1 | sudo -S $2 $3 $4 (since echo can't be be the 'program' line) which although works on the CLI, it fails to read echo-stdin on the IntelliJ console.
Ideally, I would like the solution to be configured solely from within IntelliJ and not require specific OS configuration changes outside of IntelliJ.
Perhaps there are other ways to deal with this, so lets improvise!
I, too, faced the same issue, but I work with sensitive data on my development machine and removing the password requirement for sudoers just isn't an option.
I was able to resolve this issue by launching the actual WebStorm application from the command line using the sudo command as follows:
sudo /Applications/WebStorm.app/Contents/MacOS/webide
Once WebStorm/PhpStorm are launched this way, you can run a script with root access without supplying root credentials.
Use the NOPASSWD feature of sudo. Add a rule like so to sudoers (via visudo or similar):
someuser ALL = NOPASSWD: /usr/bin/interesting_program
%somegroup ALL = NOPASSWD: /usr/bin/interesting_program
I find myself automating a lot of my workflow, and running into the same issue. I don't want to punch a hole in my sudoer permissions, and I don't want to run my IDE as root either. A good solution that I've found is gksudo, on Ubuntu and many other Linux variants you'll find it installed by default. What gksudo does is it allows you to prompt the user(yourself) to input your password with a graphic overlay, much like Ubuntu/KDE/etc. do when you need to be root to perform an operation such as an update.
This will then prompt you to provide your password to escalate privilege, then execute a given command/program as root.
In the Edit Tool Window simply:
Set the Program to /usr/bin/gksudo
gksudo may be located at a different path, try: whereis gksudo to find its path
Set Parameters to all commands you want to execute in quotes
Ex. "mongod --fork --config /etc/mongodb.conf; service elasticsearch start"
Make sure you have the quotes!
Set a working directory(if needed)
If I run a script from /home/<user>/<dir>/script.sh, as root, the cron works pretty well. But If I run the script from /root/<dir>/script.sh (as root, again), the cron does not seem to work.
Having run afoul of various default $PATHs in the past when using 'cron', I always spell in full the absolute $PATH for each executable file and each target file. I always assume that 'cron' has NO $PATH set and has NO current-working-directory.
In other words don't use a command like
"myprocess abc*.txt"
but do it in full like
"/usr/localbin/myprocess /home/jvs/abc*.txt".
Alternatively, create a bash script which does the job, and call that bash script with a full absolute path, such as
"/usr/local/bin/myprocess_abc_txts".
If you need to have some flexibility in the script, use environment variables which are set specifically within the bash script you call with 'cron'.
I think you need to add a little more information. I'd guess it is a permissions thing though. Add the permissions of the file, the directories, and the line in your crontab so we can help. Also, if you are putting this in /root, are you running this in root's crontab?
Remember the environment - especially when run by cron rather than by root. When cron runs something, you probably don't have anything much set of your environment, unlike when you run a command via at. It is also not clear what your current directory will be. So, for commands that will be run by cron, use a script (as you're already doing) and make sure it sets enough of the environment for it to run. And make sure your environment setting code is not interactive!
On my machines, I have a mechanism such that the cron entry reads (for example):
23 1 * * 1-5 /usr/bin/ksh /work1/jleffler/bin/Cron/weekday
The weekday script in the Cron directory is a link to a standard script that first sets the environment and then runs the command /work1/jleffler/bin/weekday (in this case - it uses the name of the command to determine what to run).
The actual script in the Cron directory is:
: "$Id: runcron.sh,v 2.1 2001/02/27 00:53:22 jleffler Exp $"
#
# Commands to be performed by Cron (no debugging options)
# Set environment -- not done by cron (usually switches HOME)
. $HOME/.cronfile
base=`basename $0`
cmd=${REAL_HOME:-/real/home}/bin/$base
if [ ! -x $cmd ]
then cmd=${HOME}/bin/$base
fi
exec $cmd ${#:+"$#"}
I've been using it a while now - this version since 2001 - and it works a treat for me. I'm using a basic (Sun Solaris 10) implementation of cron; there may be new features in new versions of cron on other platforms to make some of this unnecessary. (The $REAL_HOME stuff is a weirdness of mine; pretend it says $HOME - though that makes some of the script unnecessary for you.) The .cronfile is responsible for the environment setting - it does quite a lot, but that's my problem, not yours.
It could be because you're looking for relative directories/files in the script which are located when running it from /home/ but not from /root, because /root is not in /home/root nor would it look like a users homefolder in /home/
Can you check and see if it is looking for relative files, or post the script?
On another note, why don't you just set it to run from a user's homefolder then?
Another way to run sh script is place your bash script in /usr/bin directory and simply run command bash yourscript.sh without adding /usr/bin/ directory