SUMM: After upgrade 4.0B - 4.0D -> weird cron

From: Peter van Empel <Peter.vanEmpel_at_kub.nl>
Date: Tue, 20 Oct 1998 11:14:56 +0200

I was directed to the solution of the crontab -e question, when I read the man
page of crontab of Solaris!

NOTES
..
..
    If a super-user modifies another user's crontab file,
     resulting behavior may be unpredictable. Instead, the
     privileged user should first su(1M) to the other user's
     login before making any changes to the crontab file.

Well, this was the problem because I did all my test with superuser. The
superuser may edit the crontab-files of other users but they have no effect.
Dec-support confirmed that when they looked at the source-code of crontab -> a
whoami is done and rereads the crontab of that specific user who is actually
editting. In my case everytime the root crontab-file..

So crontab -e <username> does only take effect when restarting cron.


- the only thing that isn't solved is the timestamp every quarter of the FIFO.


Peter van Empel
Tilburg University
Holland


--------------original message ----------------------------------------------

Last weekend I upgraded a 1000A 5/400 from 4.0B to 4.0D (incl. patch
duv40das00002-19980717)
 Everything seems oke till someone noticed me the anomalous functionality of
cron.

It seems that after the systemstartup of cron it reads the crontab-files in
memory only once. After that moment cron wont reread a modificated
crontab-file for normal users (it does for the crontab-file of root!).

Everytime a normal user modificates his crontab-file (with crontab -e) , the
FIFO get's the correct timestamp of change (this should be the trigger for
cron to reread all the crontab-files, but it doesn't except for the root
crontab-file).

When I stop and start cron, then it takes -off course- the actual
crontab-files.
 
An additional strange thing is that the FIFO's timestamp changes every 15
minutes (00-15-30-45).
In /var/adm/cron/log you can see that it is only start at systemstartup or by
manual restart.
What is responsible for this punctual change? (is it 'at' like DEC-support
thought)
Why does this trigger not work?


technical info:
---------------
> ls /var/spool/cron/crontabs/
-rwxr-xr-x 1 bin bin 1805 Nov 16 1996 adm
-rwxr-xr-x 1 root system 413 Jan 5 1998 cronuucp
-r-------- 1 root system 1056 Oct 14 13:13 lbs_prod
-r-------- 1 root system 61 Oct 12 14:28 pve
-r-------- 1 root system 1077 Oct 15 10:38 root
-r-------- 1 root system 899 Oct 10 14:47 root.PreMRG
-r-------- 1 root system 625 Oct 15 10:22 sybase
-rwxr-xr-x 1 bin bin 1555 Nov 16 1996 sys
lrwxrwxrwx 1 root system 10 Oct 10 14:48 uucp -> ./cronuucp



>ls -l /var/adm/cron/cron*
-rw-r--r-- 1 root system 33 Dec 9 1997 cron.allow
-rwxr-xr-x 1 bin bin 1741 Nov 16 1996 cron.deny

>more /var/adm/cron/cron.allow
root
lbs_prod
sqruser
sybase
pve


>cron.deny is 'empty'

>more queuedefs
b.50j20n60w


>umask: 022

>ls /usr/bin/crontab
-rwsr-xr-x 1 root bin 40960 Mar 10 1998 /usr/bin/crontab
checksum: 53863 40 /usr/bin/crontab

>ls /usr/sbin/cron
-rwxr-xr-x 1 bin bin 49152 Oct 13 11:10 /usr/sbin/cron
checksum: 64540 48 /usr/sbin/cron


TX
-- 
===============
Peter van Empel 
Tilburg University 
Holland
------- End of Forwarded Message
Received on Tue Oct 20 1998 - 09:15:59 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:38 NZDT