Hello

I am trying to run a Crontab job as su/root, but am unsure how to do this. I have other cron jobs running just fine, but not as su/root. Does anybody know how to make this work?

Thanks
Harpo

I don't understand the question. The way to make cron jobs run as the root user is to put the job in root's crontab. There is no need to and plenty of reason NOT to do an su to root from within a cron script.

To update root's crontab you of course have to be root:

Become root user (requires you to know the password):
su -

Edit root's crontab after the su -:
crontab -e

This puts you in a vi session - you make your changes then :wq! and it saves them. You can verify they're OK by doing:
cat /var/spool/cron/root
(this IS the crontab for root).

In Kubuntu, it is under /etc/crontab. I see a field that says "user", and several entries that say root. This field is not under my user crontab.

/etc/crontab is an alternate way of doing cron.

It's better IMO to do it the way I said. If for no other reason than because most UNIX variants don't have /etc/crontab so doing it the other way insures you're consistent across Linux/UNIX environments so you only have to remember one way.

The syntax in /etc/crontab is different - it contains "root" to tell it to run those jobs as root. The root crontab I mentioned earlier doesn't need such a field because it is named root so cron understands to run everything it contains as root.

Thank you. I was responding to the question at the same time you were, and I saw your post after I hit submit...your idea is better. I tend to approach things from a distro-centric point of view until I learn more.

No worries.

I try to avoid distro/variant centric ways of doing things just because I'm lazy. I'd rather remember the generic way (e.g. /etc/init.d/<service> start) than the centric way (e.g. service <service> start for Linux) just because it keeps my little brain from getting crammed with too much.

It's not always possible though. HP-UX has "bdf" which works much better than it's "df -k" and it doesn't have "df -h" like Linux. I do however avoid things like HP-UX's "ll" which is just a shortcut command for "ls -l" as "ll" only exists on HP-UX. I could create aliases or scripts on other hosts but they might not be available if I had to sit down at some foreign system. An example of that would be recent testing I did offsite at an Oracle testing facility where I had no access back to my company's servers.

Thank You jlightner. That is how I made the cron job, however, when it runs the program (chkroot), it says permission denied. I assumed (apparently incorrectly) that it was because the cron was not root. Any other ideas on why I would get permission denied?

Harpo

If the file for chkroot isn't executable for root it will give you that (even though root can override permissions).

Also it's possible it IS running chkroot but something within chkroot is getting the permission denied message instead.

What is the exact error you're seeing and where are you seeing it? Do you have the line in cron redirecting to a log file?
e.g. 30 3 * * * /root/myprog.sh >/root/myprog.out 2>&1

Would make it send output (stdout and stderr) to myprog.out. The cron log (/var/log/cron) won't give you details - it will simply show the start and return code of the job. You have to do something like the above redirections to get detailed output from the line in cron.

For even more detailed output you can put echo statements within myprog.sh at key points.
e.g. echo "Now doing the flippity-flop routine"

Also remember cron is not like a user shell. You have to be sure to give full paths for commands you're executing within the script.
e.g. /usr/bin/awk instead of just awk
Or you can define PATH within the script itself.

P.S. You verified this shows up in the root crontab? If you were logged in as a different user when you did crontab -e it would have created a file for that user rather than editing the one for root.

jlightner

I can run my script from console as su, but, cron can't run it it now says line 1 chkrootkit command not found. I have made the script executable by root, but no change. I made the crontab job exactly as you had stated in an earlier post. When I do su crontab -e it shows up there. Within the cron job, do I have to place root in there somewhere such as:
* * * * * root /home/name/script.sh
or something to that effect?

Harpo

line 1 of chkrootkit would likely mean it IS running the cron job but saying it can't find the command you have in the first line of chkrootkit itself.

Look at what I said about PATH earlier. Scripts that run fine at command line often do not run in cron. This is because when you login as a user you execute /etc/bashrc or /etc/profile then $HOME/.bashrc and/or $HOME/.bash_profile or $HOME/.profile. These files build your environment. Any command you execute at the command line inherits your environment.

cron on the other hand doesn't actually "login" and it doesn't really run the full shell. Because of this you have to insure there is an environment in the shell script if you want it to run like it did from command line. The MOST common environment item missing is the PATH variable. PATH tells it where to look for exeuctable files (binaries and scripts).

So if you login and do "echo $PATH" you'll see multiple things separated by colons (. Each of these are directories to search for desired command. If you do "echo $PATH" it will show you what is in this variable (env shows you all of your environment). So say your path shows for example:
/bin:/usr/bin:/usr/local/bin
And you type "ls -l" it looks in /bin to find the "ls" command then /usr/bin then /usr/local/bin (it actually stops when it finds the first one so if it finds it in /usr/bin it won't look in /usr/local/bin).
When you run the cron job however it doesn't know where to look for "ls" so would just say "not found".

You could source in the environment building files listed earlier but usually don't want to because they often contain information related to setting your terminal type, display or other other variables that aren't relevent to a cron session so you get a lot of garbage in your log.

The 3 ways to solve this are:
1) Type in full path of each command every time you use it.
e.g. /bin/ls instead of just ls.
-OR-
2) Define the command itself as a variable then use the variable itself in the script body instead of typing the command.
e.g. LS=/bin/ls then put $LS everywhere you would have put ls.
this saves typing in the rest of script and makes it easier to read later.
-OR-
Just set the PATH variable for all the paths you know you'll need.
e.g. PATH=/bin:/usr/bin:/usr/local/bin

One caveat on the last method don't put in something like:
PATH=/bin:/usr/bin:/usr/local/bin:$HOME/bin
That syntax would work in your bashrc but not in a script run from cron because there isn't really a home directory for cron.

In answer to your other question - no the word "root" should not appear in the crontab that is edited by typing "crontab -e". Including the word root is for the alternate cron file that was mentioned by another poster. That file has a different format.

jlightner

All is well now. I didn't have the correct path as you had suggested. I had the path to my script in cron correct, but my script did not point to the correct path for program to run. Thank you very much for your directions

Harpo

No problem. Glad I could help.