Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

I've checked most of the treads that address this problem on this forum but nothing works for me. With the same configuration the same script runs on debian / ubuntu / centos / redhat servers. But it won't run on Slackware.

root@ums:/opt/backup/run# cat /var/spool/cron/crontabs/root
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null. We'll do this here since these jobs should run
# properly on a newly installed system, but if they don't the average newbie
# might get quite perplexed about getting strange mail every 5 minutes. :^)
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this. If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
55 23 * * * /opt/backup/run/run.sh

I've also tried without the .sh extension, have a "run" script.

The script runs perfect manually. Also there are entries in the cron log

root@ums:/opt/backup# crontab -l root
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null. We'll do this here since these jobs should run
# properly on a newly installed system, but if they don't the average newbie
# might get quite perplexed about getting strange mail every 5 minutes. :^)
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this. If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
39 15 * * * /opt/backup/run/run.sh
39 15 * * * /opt/backup/run/temp.sh

temp.sh

Code:

#!/bin.sh
echo running > /opt/temp.log

file wasn't created ...

I've also tried with #!/bin/bash. Nothing.

EDIT: I've made an error in the temp script (#!/bin.sh instead of #!/bin/bash or #!/bin/sh ). Yes the temp log was created. But my script didn't run.

Typo: #!/bin.sh for #!/bin/sh but if you got #!/bin/bash right that's not the issue. You could try increasing cron of crond (depending on which cron system you have) logging level. Details in cron or crond man page.

Typo: #!/bin.sh for #!/bin/sh but if you got #!/bin/bash right that's not the issue. You could try increasing cron of crond (depending on which cron system you have) logging level. Details in cron or crond man page.

yes, made the correction and made the output but the run.sh script still didn't do anything. any ideas how i can change the logging lvl in cron ? i'm not at all used to slackware, can't find his services or auto run

Since the script runs ok manually, and does indeed depend on JAVA_HOME, which I had set. I assumed it should be ok for cron too. But I've never checked, I use the same config on some debian / centos boxes and never had a hitch like this.

I don't understand why temp.sh didn't produce /opt/temp.log though; that has nothing to do with Java.

cron sets a limited environmemt. If you want the same environment as when logged on, add -l (letter l) to the shebang line; that makes the shell simulate a logon.

Threads can be marked SOLVED via the Thread Tools menu.

I had mentioned in my reply that after correcting the #/bin.bash into #!/bin/bash it worked "EDIT: I've made an error in the temp script (#!/bin.sh instead of #!/bin/bash or #!/bin/sh ). Yes the temp log was created. But my script didn't run."