dave@norsat.UUCP (Dave Binette) (04/21/89)
Our SCO XENIX 2.3.1 installation of usenet news suggests installing lines
such as 9,39 * * * * ulimit 5000; /bin/su -c "/usr/lib/uucp/uu...
Can anyone tell me why this 'su' is neccessary?
The OS supports multiple crontabs:
/usr/spool/cron/crontabs/root
/usr/spool/cron/crontabs/uucp
/usr/spool/cron/crontabs/news
and enables them with:
/usr/lib/cron/cron.allow which contains:
root
uucp
news
The new crontab is enabled with the command:
crontab [filename]
( I get strange behaviour if i just edit the crontab/uucp file without
submitting the changes via crontab {like it gets ignored} )
---
usenet: {uunet,ubc-cs}!van-bc!norsat!dave (Dave Binette)
bbs: (604) 597 4361 3/12/24/PEP
voice: (604) 597 6298
--
usenet: {uunet,ubc-cs}!van-bc!norsat!dave (Dave Binette)
bbs: (604) 597 4361 3/12/24/PEP
voice: (604) 597 6298jpr@dasys1.UUCP (Jean-Pierre Radley) (04/26/89)
In article <75@norsat.UUCP> dave@norsat.UUCP (Dave Binette) writes: >Our SCO XENIX 2.3.1 installation of usenet news suggests installing lines >such as 9,39 * * * * ulimit 5000; /bin/su -c "/usr/lib/uucp/uu... You mean /bin/su uucp -c "usr/lib/uucp/uu..." , don't you? ^^^^ >Can anyone tell me why this 'su' is neccessary? These daemons should run as user 'uucp', not because 'root' is incapable of so doing, but because any resulting mail is from 'uucp', so presumably more meaningful, and all the various log entries also leave a better trail. >The OS supports multiple crontabs: >/usr/spool/cron/crontabs/root >/usr/spool/cron/crontabs/uucp >/usr/spool/cron/crontabs/news plus any others YOU wish. >/usr/lib/cron/cron.allow which contains: >root >uucp >news plus whatever YOU add. >The new crontab is enabled with the command: >crontab [filename] >( I get strange behaviour if i just edit the crontab/uucp file without > submitting the changes via crontab {like it gets ignored} ) The manual says exactly what it means. To have a different set of cron commands, "crontab newtable" is the command you need to execute, not any editing of an existing table. So many folks think cron is broken in SCO because they edit a crontable directly, and nothing seems to happen. Nothing does happen... Easy way to change your crontable: vi :0r !crontab -l # read in existing crontable [ do your editing, in vi, to your heart's content; then: ] :%w !crontab # submit vi's buffer to crontab :q! If you are root and you want to change uucp's crontable, then change the first line above to: su uucpmgr -c vi # NOT uucp, you'd be running uucico # instead of uucpmgr's shell. -- Jean-Pierre Radley Honi soit jpr@dasys1.UUCP New York, New York qui mal ...!hombre!jpradley!jpr CIS: 76120,1341 y pense ...!hombre!trigere!jpr
plocher%sally@Sun.COM (John Plocher) (04/27/89)
>>such as 9,39 * * * * ulimit 5000; /bin/su -c "/usr/lib/uucp/uu... >>Can anyone tell me why this 'su' is neccessary? > > These daemons should run as user 'uucp', not because 'root' is > incapable of so doing, but because any resulting mail is from 'uucp', > so presumably more meaningful, and all the various log entries also > leave a better trail. The reason this is done in root's crontab is because only root can INCREASE the ulimit; the su is done for the above reason. If you put this into the uucp crontab entry you couldn't increase ulimit.. >>The new crontab is enabled with the command: >>crontab [filename] >>( I get strange behaviour if i just edit the crontab/uucp file without > Easy way to change your crontable: > > vi > :0r !crontab -l # read in existing crontable > [ do your editing, in vi, to your heart's content; then: ] > :%w !crontab # submit vi's buffer to crontab > :q! I have a shell script called /etc/vict which contains: -- -- /etc/vict -- -- -- |# | |F=/tmp/vict$$ | |crontab -l > $F | |vi $F | |crontab < $F ; rm $F | -- -- -- -- -- -- -- -- -- just su to whatever id you wish and type /etc/vict -John Plocher
edhew@egvideo.UUCP (Ed Hew) (04/29/89)
In article <75@norsat.UUCP> dave@norsat.UUCP (Dave Binette) writes: >Our SCO XENIX 2.3.1 installation of usenet news suggests installing lines >such as 9,39 * * * * ulimit 5000; /bin/su -c "/usr/lib/uucp/uu... > >Can anyone tell me why this 'su' is neccessary? Without any research or certainty, I will hazard a guess that many sites would have restricted fileperms on some if not all of the files accessed by these crontabs entries, hence the need for a bit more power via the su command. I know that's the case here on my site. If anyone in SCO SoftTech is looking at this, a confirmation or correction is welcome. >The OS supports multiple crontabs: >/usr/spool/cron/crontabs/root >/usr/spool/cron/crontabs/uucp >/usr/spool/cron/crontabs/news > >and enables them with: >/usr/lib/cron/cron.allow which contains: >root >uucp >news Well, I don't know if the word "enable" is the correct one to be using here. It's my understanding that if you have a cron.allow file, then the specific user must be included in order for that user (root, uucp, news all being users for the sake of this particular part of the discussion) to be able to issue a cron'd command. If you *don't* create the cron.allow file, then the contents of the cron.deny file in /usr/lib/cron will take precedence in the opposite manner. >The new crontab is enabled with the command: >crontab [filename] Ok, what we're doing here is "installing" the new (modified) crontabs entry (read: modified file), ie, telling cron that changes have been made and/or that the file has been created (if it's a new file). I would caution to always install the file with crontab while logged in as the user who's name you want the file to bear. For eg. if you log in as root and use crontab to install your "uucp" crontabs file, there is a very good chance that crontabs will overwrite your existing root file with the contents of your uucp file, which is *not* what you want to do. I was not at all amused when that happened to me. >( I get strange behaviour if i just edit the crontab/uucp file without > submitting the changes via crontab {like it gets ignored} ) The last time I read RTFM, it said somethink like: "Cron reads the contents of /usr/spool/cron/crontabs _periodically_". "periodically" appears to mean when cron is restarted, which normally happens on bootup, however if you already have used crontab to initially install your /usr/spool/cron/crontabs/uucp file, then merely killing off cron and restarting at an opportune moment will force cron to read it. The crontabs command in it's current incarnation is new to 2.3.1 (SCO). Previously, merely killing and restarting cron would always do the trick. --ed {edhew@egvideo.uucp} >usenet: {uunet,ubc-cs}!van-bc!norsat!dave (Dave Binette) Ed. A. Hew Technical Trainer Xeni/Con Corporation work: edhew@xenicon.uucp -or- ..!{uunet!}utai!lsuc!xenicon!edhew home: edhew@egvideo.uucp -or- ..!{uunet!}watmath!egvideo!edhew # I haven't lost my mind, it's backed up on floppy around here somewhere!
karish@forel.stanford.edu (Chuck Karish) (05/01/89)
In article <2008@egvideo.UUCP> edhew@egvideo.UUCP (Ed Hew) wrote: >In article <75@norsat.UUCP> dave@norsat.UUCP (Dave Binette) writes: >>Our SCO XENIX 2.3.1 installation of usenet news suggests installing lines >>such as 9,39 * * * * ulimit 5000; /bin/su -c "/usr/lib/uucp/uu... >> >>Can anyone tell me why this 'su' is neccessary? > >Without any research or certainty, I will hazard a guess that many sites >would have restricted fileperms on some if not all of the files accessed >by these crontabs entries, hence the need for a bit more power via the su >command. I know that's the case here on my site. But 'su' will fail unless the command is already being run with root privilege! As written above, the '/bin/su -c' is redundant. It probably should be '/bin/su uucp -c...'. It's common to use sych a construction as a security precaution. If someone manages to cause uux or uucico or some such to do something naughty, it will be done with uucp's privileges rather than with root's. Chuck Karish {decwrl,hpda}!mindcrf!karish (415) 493-7277 karish@forel.stanford.edu
guy@auspex.auspex.com (Guy Harris) (05/02/89)
>>( I get strange behaviour if i just edit the crontab/uucp file without >> submitting the changes via crontab {like it gets ignored} ) > >The last time I read RTFM, it said somethink like: >"Cron reads the contents of /usr/spool/cron/crontabs _periodically_". That sounds like the old (pre-S5R2) "cron", which checked the one and only "crontab" file, in "/usr/lib/crontab" or wherever, once a minute. The S5R3 "cron" and, I think, the S5R2 "cron", do not check any of the "crontab" files unless they're told to; the "crontab" command tells it to after updating the "crontab" file, which is why you have to use the "crontab" command instead of just editing the file.
dewey@sequoia.UUCP (Dewey Henize) (05/02/89)
In article <1524@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > >The S5R3 "cron" and, I think, the S5R2 "cron", do not check any of the >"crontab" files unless they're told to; ^^^^^^^^^^^^^^^^^^^^^^ Can someone who's looking at source or speaking from experience tell me, please, HOW they're told to? Is there a signal that could be used? It would seem the most 'unixy' thing, but I've not found it in any of our docs, and we don't have any source... Thanks in advance. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ...!cs.utexas.edu!execu!dewey or | "If you will just quit shouting at me, I | | ...!natinst!sequoia!dewey | will try to hear what you are saying" | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | If I so often disagree with my company, of course these ideas are mine | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
stevea@laidbak.UUCP (Steve Alexander) (05/03/89)
In article <483@sequoia.UUCP> dewey@sequoia.UUCP (Dewey Henize) writes: >Can someone who's looking at source or speaking from experience tell me, please, >HOW they're told to? Is there a signal that could be used? It would seem the >most 'unixy' thing, but I've not found it in any of our docs, and we don't have >any source... Crontab(1) sends messages to cron(1M) via the named pipe /usr/lib/cron/FIFO. A generic message contains a type, an action, a filename, and a login name. Messages from crontab(1) pass the user's login name as the crontab file name, with a type of 'c' for crontab. An action is either adding or deleting a crontab file. I don't think that the login name field is used by the crontab command. This pipe is also used by at(1). Only root processes can read and write the pipe. -- Steve Alexander, TCP/IP Development | stevea%laidbak@sun.com Lachman Associates, Inc. | ...!sun!laidbak!stevea
bill@bilver.UUCP (bill vermillion) (05/03/89)
In article <2008@egvideo.UUCP> edhew@egvideo.UUCP (Ed Hew) writes: > >>( I get strange behaviour if i just edit the crontab/uucp file without >> submitting the changes via crontab {like it gets ignored} ) > >The last time I read RTFM, it said somethink like: >"Cron reads the contents of /usr/spool/cron/crontabs _periodically_". > >"periodically" appears to mean when cron is restarted, which normally >happens on bootup, however if you already have used crontab to initially >install your /usr/spool/cron/crontabs/uucp file, then merely killing off >cron and restarting at an opportune moment will force cron to read it. > It used to be that way (kill the cron and restart it, but your quote from the manual wasn't quite complete. "cron exmains the crontabs directory periodically to see if it has changed; if it has, cron reads it. Thus it takes only a short while for entries to become effective" That was a welcome change. I forgot to kill the cron on more than one occasion in the past. Thought I had typed the file wrong - arg! (;-) :-) bill -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
guy@auspex.auspex.com (Guy Harris) (05/03/89)
>>The S5R3 "cron" and, I think, the S5R2 "cron", do not check any of the >>"crontab" files unless they're told to; > ^^^^^^^^^^^^^^^^^^^^^^ >Can someone who's looking at source or speaking from experience tell me, please, >HOW they're told to? Go back and reread my posting; you do so by using the "crontab" command. >Is there a signal that could be used? No, in the current implementations shipped by AT&T, it's done by sending something over a named pipe. HOWEVER, this does not necessarily mean that it's done that way on implementations done independently of the AT&T code, nor does it necessarily mean that it'll be done that way in all AT&T versions henceforth and forever more, world without end, amen. Moral: use the "crontab" command. Don't depend on the unpublished details of a particular implementation.
dewey@sequoia.UUCP (Dewey Henize) (05/03/89)
[>> is me (Dewey Henize)] In article <1545@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>>The S5R3 "cron" and, I think, the S5R2 "cron", do not check any of the >>>"crontab" files unless they're told to; >> ^^^^^^^^^^^^^^^^^^^^^^ >>Can someone who's looking at source or speaking from experience tell me, please, >>HOW they're told to? > >Go back and reread my posting; you do so by using the "crontab" command. > Easy, relax. I'm not trying to do anything unnatural or perverted here :-) I DID read the posting, and as a matter of fact, on the machines we have that run the multiple crontab implementation, that is in fact what I do. I asked about the mechanism because I wished to understand it, and because there have been occasions when a user has NOT followed that procedure. I don't have 100% control of the machines on 'my' <ahem> network, many of our users have a lot of access. (Most are real good people, too, and don't deliberately mess things up.) Occasionally someone does some things without RTFM though, and it would be nice to be able to send a signal or whatever to quickly fix a problem if that were a known way to get things back on track. Sorry to upset you. Dewey -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ...!cs.utexas.edu!execu!dewey or | "If you will just quit shouting at me, I | | ...!natinst!sequoia!dewey | will try to hear what you are saying" | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | If I so often disagree with my company, of course these ideas are mine | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
pjh@mccc.UUCP (Pete Holsberg) (05/04/89)
SVR3 SysAdm Ref Man says:
cron only examines crontab files and at command files during
process initialization and when a file changes via crontab
or at. This reduces the overhead of checking for new or
changed files at regularly scheduled intervals.
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800guy@auspex.auspex.com (Guy Harris) (05/04/89)
>I asked about the mechanism because I wished to understand it, Well, as was indicated in the part of my posting you didn't cite, "crontab" sends a message over a named pipe. The named pipe is generally named "FIFO"; its location differs. The message basically tells "cron" that a "crontab" file is to be reread, and which file it is. (Other messages are used for deleting "crontab" files and for submitting and deleting "at" jobs.) >Occasionally someone does some things without RTFM though, and it >would be nice to be able to send a signal or whatever to quickly >fix a problem if that were a known way to get things back on track. The way to quickly fix the problem is to resubmit the "crontab" file through "crontab" - if the only copy left is the one in "crontabs/<wherever>", make a copy of it and hand it to "crontab" - standard procedure. You really don't need to know the subject-to-change-without-notice details of how "crontab" works to do this. (And one problem with people knowing about it is that it becomes harder to change - that's one reason why Sun never published the ND protocol; they didn't want anybody to use it themselves and make it hard for them to nuke ND.)
vjs@rhyolite.SGI.COM (Vernon Schryver) (05/04/89)
In article <532@bilver.UUCP>, bill@bilver.UUCP (bill vermillion) writes: > ... > "cron exmains the crontabs directory periodically to see if it has changed; if > it has, cron reads it. Thus it takes only a short while for entries to become > effective" > > That was a welcome change... It would indeed be a welcome change to go back to the old behavior when cron would regularly stat(2) the file /usr/lib/crontab. However, a quick check of the SVR3.2 source suggests to me that cron only calls dscan() from read_dirs(), which is only called from initialize(), which is only called (1) at the beginning, (2) when time appears to have run backwards, (3) and when time appears to have jumped more than 120 seconds past the second when the next event was expected to finish. What am I misunderstanding? Checking the mtime of the directory would be useful, but not perfect, since an aging hack is likely to `vi /usr/spool/cron/crontabs/root`, and not bother to `touch /usr/spool/cron/crontabs`. Thus, you would probably want cron to stat(2) every file in /usr/spool/cron/crontabs. A handy thing added to SGI's version of SVR3 cron is to have cron pay attention to SIGHUP, closing and re-opening the log file. This allows the log to be rotated without the stupid console message. Vernon Schryver Silicon Graphics vjs@sgi.com
les@chinet.chi.il.us (Leslie Mikesell) (05/06/89)
In article <32031@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >It would indeed be a welcome change to go back to the old behavior when >cron would regularly stat(2) the file /usr/lib/crontab. >What am I misunderstanding? If you have the "crontab" command you are supposed to: crontab -l >file edit file crontab file How cron is notified of the change or where the file is stored is not really important. If you want to change another user's crontab entry, just: su user and follow the same procedure. Les Mikesell
exodus@cheers.UUCP (Greg Onufer) (05/07/89)
In article <8369@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > If you have the "crontab" command you are supposed to: > crontab -l >file > edit file > crontab file Or, in SunOS 4.0 and very likely AT&T SVR4, crontab -e username will do what you want. It will bring up an editor, let you make changes, verify the changes for correctness, and re-submit the file to cron. None of that `su user' hassle that SV systems make you go through. There's even crontab -l username if you like doing it the old way.... greg