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
Related
I want to run series of commands in bash shell file. But one of the command requires reboot of the system and I have added reboot command in the shell file. But after the reboot that process is lost. Is there any solution for this?
In the system the only thing that is really persistent is a file. That's pretty much what you should use.
Try making the part of the script that needs to be executed after reboot in to /etc/rc.local from within the script.
Reference
I have a script abc.sh and I have scheduled it in crontab.now abc.sh is calling another script using sudo. When I am executing abc.sh manually it is working fine..but from scheduler abc.sh is running every 5 minutes but It is unable to call another script using sudo. This is strange for me..can any one help me on this please
You can take a look at /var/mail/<username> file to see if cron job is sending some error or warning message. Or maybe you have not set executable permissions for the /opt/clearcache.sh file?
This happens often when people use sudo.
The environment YOU use is not set for the privileged user. As such, your $PATH and other environment variables may not be set as you expect.
You can set this up, or change the sudo behavior... however most people simply work-around this by using full paths to files in cron.
Have a look at this post as well: Where can I set environment variables that crontab will use?
When beginning to work, I have to run several commands:
source work/tools
cd work/tool
source tool
setup_tool
Off course, doing this a few times a day is really annonying, so I tried to make a bash script tool where I put these commands and put it in /user/bin to run it with command
tool
However, there is a problem. When i run the script and then try to work by typing some of the tool-based commands, it does not work.
I figured out, that it is fine, since if I make a script and then run it, the script seems to run in the same terminal window, but what it really does is, that it behaves as if it created a "hidden window" for its execution and after termination of the script, the "hidden window" terminates too. So I am asking - is there a way to automatize the source command?
I have tried using xterm -hold -e command, but it runs the programmed script in the new window. Obviously, I don't want that. How can I achieve running it in the current window?
Don't put files like that in /usr/bin. As a general rule you don't want to mess with the distribution owned locations like that. You can use /usr/local/bin if you need a system-wide location or you can create a directory in your home directory to hold things like this that are for your own usage (and add that to the $PATH).
What you've noticed is that when run as a script on its own (tool, /path/to/tool, etc.) that the script runs in its own shell session (nothing to do with terminal windows as-such) and you don't want that (as the changes the script makes don't persist to your current shell session).
What you want to do instead is "source"/run the script in your current session. Which you are already doing with that set of commands you listed (source work/tools is doing exactly that).
So instead of running tool or /path/to/tool instead use source /path/to/tool or . /path/to/tool.
As fedorqui correctly points out you don't even need a script for this anywhere as you can just make a shell function for this instead (in your normal shell startup files .bashrc, etc.) and then just run that function when you need to so that setup.
Be careful to use full paths for things when you do this though since you, presumably, want this to work no matter what directory you happen to be in when you run it.
It doesn't create a new hidden window, nor does it create a terminal. What happens is that if you're running a script, normally it runs on a new shell process. The script you're running is supposed to modify the shell environment, but if you're running the script in a new shell process, that shell process's environment is the one that gets modified, instead of your shell environment.
Scripts that needs to modify the current shell environments usually must be run with the source command. What you need to do is to run the script in the current shell. So you should do source /path/to/tool.
If you want to be able to source the script with just tool, put this in your alias file/shell startup (check your distro doc where the file is, but it's usually either .bash_aliases or .bashrc):
alias tool="source /path/to/tool"
When I try to run a Perl script which is called via Linux script manually it works fine but not executable via CRON.
Linux_scrip.sh conatains Perl_script and the command is,
perl_path/perl Perl_script.pl
I got perl_path using which perl command.
Can anyone suggest why is it not executable via CRON entry.
Most likely suspects:
Current work directory isn't as expected.
Permission issues[1].
Environment variables aren't setup as expected.
Requirement of a terminal can't be met.
See the crontab tag wiki for more pitfalls and some debugging tips.
The first thing you should do is to read the error message.
This isn't likely to be an issue for you own cron job, but I've included it since it's quite a common problem for scripts run from other services.
Most probable cause is current working directory.
Before perl command execution, write a command to change directory.
Something like :
cd perl_path;
perl Perl_script.pl
I'm struggling trying to debug a cron job which isn't working correctly. The cron job calls a shell script which should unrar a rar file - this works correctly when i run the script manually, but for some reason it's not working via cron. I am using the absolute file path and have verified that the path is correct. Has anyone got any ideas why this could be happening?
Well, you already said that you have used absolute paths, so the number one problem is dealt with.
Next to check are permissions. Which user is the cron job run as? Does it have all the permissions necessary?
Then, a little trick: if you have a shell script that fails and it's not run in a terminal I like to redirect the output of it to some files. Right at the start of the script, add:
exec &>/tmp/my.log
This will redirect STDOUT and STDERR to /tmp/my.log. Then it might also be a good idea to also add the line:
set -x
This will make bash print which command it's about to execute, and at what nesting level.
Happy debugging!
The first thing to check when cron jobs fail is to see if the full environment is available to the script you are trying to execute. In other words, you need to realize that a job executed via cron runs as a detached process meaning it is not associated with a login environment. Therefore whenever you try to debug a cron job that works when you execute manually, you need to be sure the same environment is available to the cronjob as is available to you when you execute it manually. This include any PATH settings, and other envvars that the script may depend on.
For me, the problem was a different shell interpreter in crontab.