I trying to include a script in my crontab as user. I used "crontab -e" to include my script there but does not seem to work. If I understand correctly it is set to run at 11:20 every day, correct?
Can anybody identify any error?
<pre>
#Sun Microsystems Inc. SunOS 5.7 Generic October 1998
$ pwd
/home/oracle
$ whoami
oracle
$ ls -l |grep CLFY
-rw-r--r-- 1 oracle dba 36803584 Nov 7 11:29 CLFY_071101.dmp
-rwxr-xr-x 1 oracle dba 162 Nov 6 15:41 exp_CLFY_script
$ crontab -l
20 11 * * * /home/oracle/exp_CLFY_script
For some reason the cronjob is not even starting. By what the logs say (and you have verified that oracle isn't in the deny files), you might want to check to see if the oracle password has expired, or if the account is disabled in any way. http://www.sunmanagers.org/archives/1999/0475.html
I'm finishing up my shift now; I'll look for more links later if you haven't got it figured out yet...
The link was usefull. I believe it is the 'oracle' user password.
I have never been given the password for oracle and the procedure is to always switch to user 'oracle' using 'su' from root account.
Do you know if I can do that, if the oracle password has expired?
Thanks alot
It is very likely that your "oracle" user environment
does not get set when you run this cron job. A sure way to deal
with this is to set up your environment explictly in the
shell script (i.e. ORACLE_SID, etc.).
When you log in as the "oracle" user, type "env"
and look for all ORA... variables and make sure to
set and export them explicitly in your shell script.
That's a definite consideration once the script executes, but I don't think cron is even attempting to run the job.
guest100, are you using shadowed passwords? If so, check the /etc/shadow file to verify that there is a valid entry in the password field (the second field). Check the man page for the shadow file (on a Linux system, it's in section 5 - not sure if it would be in the same place for Solaris or any other Unix) for details on what each field means.
Here is the oracle user shadow line in /etc/shadow
<pre>
<B>oracle:Lic8CakzDxM3o:11529:0:28:24::: <B>
username The user's login name \(UID\).
password A 13-character encrypted password for the user, a
lock string to indicate that the login is not
accessible, or no string, which shows that there
is no password for the login.
lastchg The number of days between January 1, 1970, and
the date that the password was last modified.
min The minimum number of days required between pass-
word changes.
max The maximum number of days the password is valid.
warn The number of days before password expires that
the user is warned.
So, if the maximum number of days the password is valid is = 28, does that mean that the password has expired?? No-one has changed the password, and I can switch to 'oracle' from 'root' using 'su - oracle' fine.
Do you think that I still have to set the variables in the script. The script can be seen above in past thread. I believe that it is something to do with the password, what do you think ??
Yeah, it would be to your benefit to add those variables to the top of your script. Remember that if you call sub-scripts, you may need to export the variables.
If you do change the Oracle password, <b>please</b>, for the love of Mel, pick a better password. The last/current one stunk.
This way you always have a copy of your crontab, in this case for root, and if you make any mistakes editing you are not actually messing up the crontab file itself.
I don't even know what the password is. As I said I was handed the system and the procedure was always to switch using 'su - oracle'. Anyway, there is no security issue, so no worries about it.
By the way,.is the password still valid or expired?
Also, why should I inlcude the variables to te script if already are set to env when I log in as oracle??
Kelam_Magnus,
If you read the manual about the crontabs, you will find that the ONLY way to EDIT the crontab is by using 'crontab -e'. If you edit the file itself it will NOT recognise the changes. I am using Solaris 7.
I used to use only "crontab -e" until I found this way of editing the crontab. It is much safer for you and if you make any mistakes it doesn't corrupt your crontab file.
When you look at the options for the manpage for crontab, the first options is "crontab filename".
My only point about saving the crontab out to a file and editing it is 1) so that you will have a copy of it and 2) when you edit this text file that you just saved out, you can execute "crontab filename" to replace the current crontab with the newly edited one. In addition, it prevents you from making a mistake typing while using "crontab -e".
Step 1
Copy out the crontab to a saved file.
$ crontab -l > somefile
Step 2
edit somefile and make changes.
$ vi somefile
Step 3
copy the newly edited file back into place.
$ crontab somefile
This is the safest way to edit the crontab file so that it doesn't get corrupted.
I work for a very large telecom company and this is the company standard for all platforms: SUN, HPUX, and AIX with several different versions on each platform.
In addition, yes you can go to /usr/spool/cron/crontabs and vi the file in question, edit it and save. The file will be recognized by cron because I have done this as well. I have even cut and pasted from a Word document into a telnet session while vi'ing a file in /usr/spool/cron/crontabs file. And there was no corruption of the file when I saved it and ran cron.
Trust me, all of these things work! Can someone else back me up on this? I am not trying to mess you up, only to help you out.
A few comments here. First, cron on Solaris does indeed check to see if a user's password has expired and if so refuses to run cron jobs for that user. And the error message is indeed "bad user". I have never heard of this behavior before, but I have looked this up on Sun's website. Solaris does seem to have a few surprises.
Second, run a cronjob that simply has "env >/tmp/env.out" and you see the need to set environment variables.
Finally, the technique that Kelam_Magus used is valid and a bit safer. "crontab filename" is a valid way to set your crontab.
I can NOT log in, using THAT password. But I can LOG IN switching from the root user with 'su - oracle'. If THAT is the password as you said and the password expired , isn't strange that I can switch from the root account?
This is the only way that I can use the oracle account, and it is working fine.
Yes, but as the password is no longer valid for that user shouldn't be nice to have a warning or something?
The thing is that even the account is inactive logs me in like this:
and all the functions are working. If this is the case, then I only need to reset the password and the crontab will run fine, correct?
<pre>
isgsi01(root)9: su - oracle
Sun Microsystems Inc. SunOS 5.7 Generic October 1998
$ whoami
oracle
Well... "root" is GOD on most (if not all) flavors of UNIX
so you can pretty much do anything and you woun't
get much if any warnings.
I assume that if oracle's cron job is not running
because of an expired password then reseting it may in
fact work however I have not actually tried this.
------------------------------------------------------------------------------------
CRONTAB USAGE : For Using "crontab" utility to Edit Cron Files
using Vi as the Editor, perform the below mentioned Steps.
U will get a Vi Editor Screen for editing the mentioned User's Cron File. { Only use this way to edit any Cron File, as directly editing the Cron files might corrupt the File }
------------------------------------------------------------------------------------
CRONTAB TROUBLESHOOTING : If Ur Cronjob is not getting executed correctly, Then check for the below mentioned....
Check for the Permissions of the Cron File and Syntax of its contents.
# ls -l /var/spool/cron/crontabs/
total 4
-r-------- 1 root other 310 Mar 31 12:50 backup_user
-r-------- 1 root root 424 Feb 21 21:41 root
Check the UserName Entries present in the below mentioned Files.
