Re: cron

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Les Mikesell wrote:
> Mikkel L. Ellertson wrote:
> 
>> Arbitrary? Sure. Most of the file locations used in Linux are
>> arbitrary.
> 
> The ones that were inherited from older systems usually had functional
> reasons.  The moves and renames since have mostly been arbitrary.
> 
There are functional reasions for the new ones as well - I told you
where to find them. If you do not want to know the reason, that is
your problem.
> 
>> It even specifies things like the
>> directories for system cron jobs. Funny thing - it talks about the
>> /etc/cron.d, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly
>> directories, and the /etc/crontab file.
> 
> But the resulting changes don't give any new functionality.
> 
They don't? I like being able to find all the system cron jobs that
run hourly, daily, etc in predictable places. I know if the job
doesn't run as root and/or doesn't run at the normal times, I have
to look in cron.d.

>> Or are you complaining because
>> system cron jobs and user cron jobs are in different places?
> 
> I'm complaining that for any given job, you have no idea where the entry
> that controls it would be found, and no way to describe where to look
> first.  Contrast that to the way entries in /etc/init.d, /etc/pam.d/ or
> /etc/xinetd.d are made.  For a given service there is a logical place to
> find its specific broken-up entry.  For scheduled jobs relating to a
> service there is no such logic.
> 
Sure there is - if it is a system job, run by root, you can look at
when it was started, and know where to look. If it is a user's job,
you know where to look. Weekly and monthly jobs complicate it
slightly, but not much.
>>>
>> If a user has the need for the same functionality, they can
>> implement it as well. There is nothing preventing a user from
>> creating the same structure in their home directory, and adding the
>> run-parts command to their own crontab. The only thing they can not
>> duplicate is the ability to run cron jobs as other users, or the
>> function of the /etc/cron.d directory. Then again, they should not
>> have enough cron jobs to require it.
> 
> Beg your pardon?  The reason I have computers is to do my jobs, not just
> so the system can run itself.   If cron.d has to be hardcoded somewhere,
> why shouldn't I get one too?
> 
Why? If you need it, set it up once, and forget about it. If you
have a strange setup where all users need it, set up the structure
in /etc/skel, and add creating the crontab file as part of the user
setup script. (If you have that type of user base, you need more
then useradd to create users anyway.)
>>
>> The system cron jobs are installed as part of the package they are
>> needed for. Why would you need to know where they are or edit them?
> 
> They might be wrong.  They might conflict with something else I have
> running.  Or I might want to make my own arbitrary changes.
> 
Then you should know enough about your system to know where to find
them. You make it sound like they are hard to find. For a system
cron job, it is going to be in one of a small number of locations.
And if you know it is conflicting, then you know how often it is
run, and probably when it is run, so you should know where it is.

>> If you have not done enough research to know what affect your
>> changes are going to have on the system, then you probably should
>> not be changing things. If you have done the research, then you
>> should know where to find the files. Reading the LFH or the cron man
>> page will tell you the locations. Or are you saying that there
>> should be a nice GUI to let you shoot yourself in the foot?
> 
> The GUI is irrelevant.  If there were a sensible scheme to find the
> entry controlling a given job a sensible GUI could do it, or you could
> do it with any editor.
> 
The scheme doesn't matter if you don't know when a job is run.
Changing when hourly, daily, etc jobs are run takes editing one
file, and changing one time each. The hard part is knowing the time
to use, and that problem is the same regardless of the scheme. Now,
if the job doesn't fit nicely into one of the standard frequency
folders, then you have to change it in its own file in cron.d, but
if it is in there, it should have a reason it is not running at the
standard times. (Or the packager made a mistake.)

>>> And the point of separating the system from root jobs so you have to
>>> hunt all over the place to find them?
>>>
>> Hunt all over the place to find them? If you can not find them after
>> reading the cron man page, are you sure you should be messing with
>> them?
> 
> If I give you the name of a program or the user id the job runs under,
> can you tell me where to find the entry that controls its schedule by
> reading any of those man pages or FHS entries you've mentioned?
> If I add a scheduled job as administrator myself, could you tell the
> next machine administrator where to look to find it and the other jobs
> that run as root?  Does any of this help you write a script that would
> modify a given entry on some unspecified version of a unix-like
> operating system?
> 
If you do it? Probably not. If a competent administrator does it,
sure. After all, a competent administrator is not going to use
crontab -e to create a system job. So I know I will find it in the
cron directory structure in /etc. Knowing how often the job needs to
run tells me where. If it was installed as part of an RPM package,
and I know the package, I can find it that way as well. If an admin
does something really oddball, they should document it. Notes in
/root/notes are a good idea. Comments in changed config files
explaining the change are also a good idea.

As far as creating a script, if you are not going to know the os,
then you should not be trying to modify a system config file
automatically from a script. You can check what os as part of the
script, and branch to cover the os. You should also check on the
version of cron running on the system. You know - the standard tests
 you have to make when updating a config file when you do not know
what version of the program is going to be on the system.

Now, if you are creating a script that is part of a package, and
needs cron to run a job for it, you don't have to modify any files
on systems that follow the LFH. You just drop the script in the
correct directory as part of package install, and remove it as part
of the uninstall. Much better then when we used to have to edit
/etc/crontab as part of the process. If you are using one of the
standard intervals, you don't even have to add the time and user
information to your script.

Yes, adapting to new ways of doing things can be hard. And sometimes
we find after using things for a while that there is a better way.
But complaining because things changes, or exaggerating the problem
is not the way to improve things.

If you have a problem with the way things are done, try using a
reasoned explanation of why. Saying that things are scattered "all
over the system" when there can all be found off the /etc directory,
and the directories even start with cron, is not going to help.
Saying that someone can use bad practices so that it is hard for the
next person to find them is not going to help ether. (Getting the
person to follow the standard may be worth the effort, depending on
if they will listen, or insist that their way is the way it should be.)

You have a hard time finding where a file is launched from by
looking at running processes. I like having all the daily cron jobs
in one place - it makes seeing what gets run easy. I don't like when
a daily job gets put in /etc/cron.d, because then I have to search
the files to find what files get run daily. It isn't a perfect
world. Being willing to try new ways, and giving the user a choice
of how they do things is part of Linux. If the cron setup bothers
you that much, you can always try a different distribution. It works
well for a lot of people.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux