Re: Re: cron/perl interaction gotchas i am missing?

there must be an additional script root involved

That /etc/crontab entry is pretty standard for Redhat and Debian-based distros. It means that the cron job is run as root. =) (The user contabs look different.)

# RedHat 9.0
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
[download]

I think they do things this way so that programs that need to install cron jobs can just copy a script into the appropriate directory.

--
Allolex

Comment on Re: Re: cron/perl interaction gotchas i am missing? Download Code

Replies are listed 'Best First'.
crontab directories versus user crontab files by jonadab (Parson) on Jan 31, 2004 at 02:05 UTC
I think they do things this way so that programs that need to install cron jobs can just copy a script into the appropriate directory. In particular, many .rpm packages include files that go in these directories. Apparently, rpm does not support the possibility that a package might contain individual lines that go into certain files, probably because it would not then be obvious, after other packages had been installed that put lines in there as well, which lines belonged to which packages, which would create a mess when uninstalling or upgrading packages. For this reason, many people have altogether quit using the old /var/spool crontabs anymore; everything goes into the hourly, daily, weekly, or monthly directories, unless it is set up by hand by an unprivileged user. On the desktop, unprivileged users don't usually set up cron jobs by hand, since almost everyone these days has a computer of their own and thus has root access when need be. The user crontabs are still useful for multiuser systems, especially shared servers where various people have shell accounts. I suppose they might get used on shared lab computers too, and that sort of thing, where most of the users cannot get root access to install anything in the global cron directories. (These are the same sorts of systems where people cannot install modules off of CPAN except in their home directories, and other horrid nonsense.) `$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/` [download]	[reply] [d/l]

Replies are listed 'Best First'.

crontab directories versus user crontab files
by jonadab (Parson) on Jan 31, 2004 at 02:05 UTC

I think they do things this way so that programs that need to install cron jobs can just copy a script into the appropriate directory.

In particular, many .rpm packages include files that go in these directories. Apparently, rpm does not support the possibility that a package might contain individual lines that go into certain files, probably because it would not then be obvious, after other packages had been installed that put lines in there as well, which lines belonged to which packages, which would create a mess when uninstalling or upgrading packages. For this reason, many people have altogether quit using the old /var/spool crontabs anymore; everything goes into the hourly, daily, weekly, or monthly directories, unless it is set up by hand by an unprivileged user. On the desktop, unprivileged users don't usually set up cron jobs by hand, since almost everyone these days has a computer of their own and thus has root access when need be. The user crontabs are still useful for multiuser systems, especially shared servers where various people have shell accounts. I suppose they might get used on shared lab computers too, and that sort of thing, where most of the users cannot get root access to install anything in the global cron directories. (These are the same sorts of systems where people cannot install modules off of CPAN except in their home directories, and other horrid nonsense.)

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

[reply]
[d/l]