Using account alex, I created:


When I manually run this using the same account, alex:

cd pocketmine
./pocketmine.sh start

It runs fine.

I have added this to /etc/crontab:

16 15    * * *   alex /home/alex/pocketmine/pocketmine.sh start

and it does not work at 15:16.

Can someone please tell me what I have done wrong?

  • What is the output of ls -l /home/alex/pocketmine/pocketmine.sh? Feb 1, 2016 at 15:48
  • alex@PocketMine:~$ ls -l /home/alex/pocketmine/pocketmine.sh lrwxrwxrwx 1 alex alex 40 Jan 31 21:57 /home/alex/pocketmine/pocketmine.sh -> /home pocketMine_Ctrl/pocketmine.sh
    – alexhore
    Feb 1, 2016 at 15:56
  • Also, if there is a logfile for your cron instance (usually something like /var/log/cron), you can look at that output to see what cron thinks went wrong.
    – Thomas N
    Feb 1, 2016 at 15:56
  • 1
    what is "alex" doing in crontab? Feb 1, 2016 at 15:57
  • 1
    @alexhore - yes, in this case, alex indicates the user that will run the utility. In general, /etc/crontab is used for system-related cronjobs, and users are expected to use the crontab command to configure and install their own jobs.
    – D_Bye
    Feb 1, 2016 at 16:02

2 Answers 2


In general, rather than editing /etc/crontab directly, it's easier to use the crontab command. The syntax to change a non-root user's crontab varies slightly from platform to platform. For example on Red Hat Enterprise Linux, it would be:

# crontab -e -u alex

On AIX, HP-UX and Solaris:

# crontab -e alex

You may also need to add that user to cron.allow in order for the job to run.

Good information on why a job may not have run can be found in the cron log, whose location also varies.

Edit: to answer your question directly, your direct edit probably didn't work since you didn't restart the cron daemon. crontab does this for you, yet another of its many valuable services.


If you have a script that runs properly when run from the command line in a shell but will not execute from cron, you might have a problem with the environment that cron is running in. Try appending:

2> /tmp/error.txt 

To the end of your statement that won't execute in cron to see what errors are happening during execution. Run the command with cron and read the contents of the /tmp/error.txt file.

When I had a problem running rsync from a cron file, I received the following output in my error.txt file:

ld.so.1: rsync: fatal: libiconv.so.2: open failed: No such file or directory.

The problem was that the environment wasn't set to find the needed libraries to execute the command. I added an LD_LIBRARY_PATH environment variable statement to the beginning of my script to set the LD_LIBRARY_PATH variable to the same value of the one I had in my .profile file since the script executed properly when I ran it from a shell using my profile.

"export LD_LIBRARY_PATH="/usr/lib:/usr/local/lib"

After that, it worked fine. My rsync program runs out of /usr/local/lib so I'm guessing the reference to that area is the one that solved my problem. You could also have other path problems if you don't use the full path when referring to other files in your script.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.