```
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.
Also the variables can seen below:
$ whoami
oracle
$ env |grep ORACLE
ORACLE\_BASE=/u01/app/oracle
ORACLE\_SID=CLFY
ORACLE\_DOC=/u01/app/oracle/product/8.1.6/doc
ORACLE\_HOME=/u01/app/oracle/product/8.1.6
--------------------------------------------------------------------
$ env |grep oracle
PATH=/usr/local/bin:/usr/bin:/usr/ucb:/etc:/u01/app/oracle/product/8.1.6/bin:/usr/bin:/etc:/usr/ccs/bin:/usr/openwin/bin:/usr/local/bin
ORACLE\_BASE=/u01/app/oracle
CLASSPATH=/u01/app/oracle/product/8.1.6/jdbc/lib/class/classes111.zip:
LOGNAME=oracle
ORACLE\_DOC=/u01/app/oracle/product/8.1.6/doc
HOME=/home/oracle
LD\_LIBRARY\_PATH=:/u01/app/oracle/product/8.1.6/lib:/u01/app/oracle/product/8.1.6/jdbc/lib:/u01/app/oracle/product/8.1.6/lib:/u01/app/oracle/product/8.1.6/jdbc/lib:/u01/app/oracle/product/8.1.6/lib:/u01/app/oracle/product/8.1.6/jdbc/lib
ORACLE\_HOME=/u01/app/oracle/product/8.1.6
PWD=/home/oracle
----------------------------------------------------------------------------------
$ set |grep ORACLE
ORACLE\_BASE=/u01/app/oracle
ORACLE\_DOC=/u01/app/oracle/product/8.1.6/doc
ORACLE\_HOME=/u01/app/oracle/product/8.1.6
ORACLE\_SID=CLFY
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 ??
Thanks for your help!
---
### Author:  [@LivinFree](https://community.unix.com/u/LivinFree)
#### Post date: [November 8, 2001, 8:08am UTC](https://community.unix.com/t/crontab-problem/140243/9 "2001-11-08T08:08:22Z")
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, \please\, for the love of Mel, pick a better password. The last/current one stunk.
---
### Author:  [@Kelam\_Magnus](https://community.unix.com/u/Kelam_Magnus)
#### Post date: [November 8, 2001, 8:20am UTC](https://community.unix.com/t/crontab-problem/140243/10 "2001-11-08T08:20:20Z")
I have a safer way that we use at work for editing any crontab.
$ crontab -l \> tempcron.root
$ vi tempcron.root
$ crontab tempcron.root
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.
😃
---
### Author:  [@guest100](https://community.unix.com/u/guest100)
#### Post date: [November 8, 2001, 9:11am UTC](https://community.unix.com/t/crontab-problem/140243/11 "2001-11-08T09:11:32Z")
LivinFree,
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.
Thanks alot
---
### Author:  [@Kelam\_Magnus](https://community.unix.com/u/Kelam_Magnus)
#### Post date: [November 8, 2001, 9:34am UTC](https://community.unix.com/t/crontab-problem/140243/12 "2001-11-08T09:34:42Z")
Guest100,
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.
😉 🆒
---
### Author:  [@Perderabo](https://community.unix.com/u/Perderabo)
#### Post date: [November 8, 2001, 9:39am UTC](https://community.unix.com/t/crontab-problem/140243/13 "2001-11-08T09:39:24Z")
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.
---
### Author:  [@LivinFree](https://community.unix.com/u/LivinFree)
#### Post date: [November 8, 2001, 9:53am UTC](https://community.unix.com/t/crontab-problem/140243/14 "2001-11-08T09:53:31Z")
Guest100, the password is the same as the username...
Try logging in, and you will know very quickly if Oracle can log in.
---
### Author:  [@guest100](https://community.unix.com/u/guest100)
#### Post date: [November 8, 2001, 10:31am UTC](https://community.unix.com/t/crontab-problem/140243/15 "2001-11-08T10:31:28Z")
Thanks for your replies guys,
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.
Thanks again.
---
### Author:  [@rwb1959](https://community.unix.com/u/rwb1959)
#### Post date: [November 8, 2001, 10:39am UTC](https://community.unix.com/t/crontab-problem/140243/16 "2001-11-08T10:39:11Z")
su'ing from root will always work since no password
is required. From root, you can change the orecle user password
# passwd oracle
---
### Author:  [@guest100](https://community.unix.com/u/guest100)
#### Post date: [November 8, 2001, 10:49am UTC](https://community.unix.com/t/crontab-problem/140243/17 "2001-11-08T10:49:41Z")
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?
\
isgsi01(root)9: su - oracle
Sun Microsystems Inc. SunOS 5.7 Generic October 1998
$ whoami
oracle
\
---
### Author:  [@rwb1959](https://community.unix.com/u/rwb1959)
#### Post date: [November 8, 2001, 12:15pm UTC](https://community.unix.com/t/crontab-problem/140243/18 "2001-11-08T12:15:13Z")
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.
I say... give it a shot. 😉
---
### Author:  [@shauche](https://community.unix.com/u/shauche)
#### Post date: [January 29, 2002, 2:57am UTC](https://community.unix.com/t/crontab-problem/140243/19 "2002-01-29T02:57:33Z")
1. Run the cron from root and not from oracle
2. prefix su -c oracle to the script that you want to run in cron
this will actually run the cronjob as root by su it to oracle before running the script.
hope this would help you.
we are doing exactly the same on our systems.
Milind.
---
### Author:  [@dhasarath](https://community.unix.com/u/dhasarath)
#### Post date: [March 31, 2002, 2:31am UTC](https://community.unix.com/t/crontab-problem/140243/20 "2002-03-31T02:31:41Z")
Hi
------------------------------------------------------------------------------------
CRONTAB USAGE : For Using "crontab" utility to Edit Cron Files
using Vi as the Editor, perform the below mentioned Steps.
# EDITOR=vi; export EDITOR;
# crontab -e \
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....
1. 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
1. Check the UserName Entries present in the below mentioned Files.
/etc/cron.d/cron.allow
/etc/cron.d/cron.deny
1. Check whether Daemon for Cron is running or not.
# ps -ef |grep cron |grep -v grep
root 183 1 0 Mar 28 ? 0:03 /usr/sbin/cron
1. If the Daemon is not running, Restart the Daemon as mentioned below
# /etc/init.d/cron stop
# /etc/init.d/cron start
1. If U are executing any customised Shell Scripts using Cron,
then U have to check whether proper Execute Permissions are
provided for that Cron User.
------------------------------------------------------------------------------------
If U still face any problem, Kindly get back with Proper Error Messages updated in the /var/adm/messages File.