This is a continuation of a conversation on another board where the other members lacked the expertise needed to help me. The other board focuses on PHP, but I need help with UNIX shell commands. The last post in that thread is at http://w3schools.invisionzone.com/in...dpost&p=100561 but I will quote the relevant part below.

The XML 'scheduleCommand' element basically describes a programmatic function to any server script that reads it.

The 'systems' attribute specifies all kernel names that I know of which will support the function. (Please tell me of others if you know them!)

The 'parameters' attribute specifies the names of all function arguments; the server script will retrieve these and replace each %-enclosed name in the function body with its corresponding value, then execute the function body on the shell.

In case you need more info on my project, see http://code.google.com/p/error-logger/.

Thanks!

Is there a question in there somewhere?

not sure exactly what you're trying to do... it sounds like you want to create a cron job with a script.... but cron jobs are recurring & it also sounds like you don't want them to be recurring. If that's the case, you want to use at. At can be done via the command line, executes once at the given time, then it's done.

if you want to edit a crontab via the command line, you can crontab -l to get the current crontab, edit it, then crontab <file> to update it.

So what exactly are you after?

you can use default cron file or user defined file for cron.
In either case it has to opened in editor for addition or modification.
To do it via code may be you could append the cron file with some redirection and execute crontab.

Fedora Development

The questions are in the quote. I quoted my own post from the other board.

I need to use AT to schedule CRONTAB. The task to be scheduled is a database pruning. The initial command will be run when the database is initially installed and the pruning job will occur frequently (I think weekly, but I'm open to correction). But a record will need to be pruned only after a much longer period of time, I'm thinking a year would be about right. So pruning doesn't need to start until a year after installation, because of course a record cannot be older than its database. After that, it should occur weekly.

EDIT:I'm not sure what you mean by "append the cron file with some redirection"... Could you clarify please?

BTW, the database records errors, as the name 'error-logger' implies. BTW#2, I'm also having trouble with this in WinNT, in case anyone has experience with command-line scheduling there.

Why not use AT to append a command to the user's crontab at the specified date. Something like

at now+1yr
>cat "30 5 * * 1 /path/command_to_run" > /var/spool/crontab/user
>[Ctrl D]

You may need to restart crontab for the change to take effect.

Not sure if I got the cronab entries correct or the location of crontab files (working from memory here)

Does the at queue survive reboots?

perhaps a neater solution would be to create a control file with the creation date of the database in it, and set the crontab entry to run each week from now, but to make the first thing it does to check that a year has passed from the date in the control file.

It sounds like you want 2 things:

1. run once, immediately after the DB is created (ie make clean DB ?).
Answer: run it manually.

2. run eg weekly, but only after 1yr has passed from DB create/step 1 above
Answer: schedule it weekly in crontab anyway, but ensure it has a cfg file with the DB create/clean date in it and only
actually prune data if curr date is at least 1 yr > create date.

I hear what you're saying, but I'd like to think there is a better way of doing this... namely, why must you start after one year, then continue weekly? If you're continuing weekly, then that means new data is being added. If new data is being added, then your pruning would prune new data as well. If it doesn't prune new data, then there's no reason to wait a year before starting the cron job, as the pruning must be smart enough to only prune data that is older than X. Am I wrong in thinking this? can't you prune based on a timestamp in the DB?

I mean, what you're asking to do, while it may be possible, just doesn't sound like a good idea. What if you're no longer around after a year? What if you change your mind about the pruning? What if the db schema changes in that year period?

No offense, just throwing out some "what ifs".

Does [Ctrl D] exit 'at'? And how can I simulate it?

From what I've read, this isn't necessary, but I would be more confident about that if someone else would confirm it.

Where's the current user's home directory? http://en.wikipedia.org/wiki/Cron

I think it would have to, but don't ask me.

That would work, although I don't see why it's neater.

Erm, I can't do that because I won't be there. See the below illustration. Anyway, I don't want to run the prune job that early, as there will be no records to prune. But that's when I need to schedule either the prune job or the other command that will schedule the prune job.

Why is that better than using 'at'?

Firstly, yes: My database does use timestamps. As for the rest, I think I need to illustrate what I'm thinking.

John, a system admin, installs my program on January 1, 2009, and JavaScript errors on his website immediately begin to be logged. Let's say he sets the prune job to run on Thursdays (in the installation page).

An error record isn't considered 'old' until more than one year has passed since its last occurrence. (Recurring errors increment the 'occurrences' field and update the timestamp.) So the program begins pruning on January 8, 2010 (a Thursday), and only records of those errors which haven't occurred since before January 8, 2009 will be pruned. No 'new' records would ever be pruned in this scenario.

(EDIT: I'm not sure if I will begin pruning exactly a year after installation or a year and a week... But you get the idea.)

As illustrated above, I am not the system admin; I will never be "around," except for tech support and updates. (And as this is a free hobby project, those might not be spectacular.)

I do not expect the users (system admins) to modify the schema; in fact, I would recommend that they not do so as this could break my program.

If the user changes the program settings on the configuration page, I will modify the crontab as necessary. Or at least I plan to implement that feature.

None taken.

Thanks for your time!

Does the above answer anything? However the link to AT on the page may help (echoing to AT) http://en.wikipedia.org/wiki/At_%28Unix_command%29

Re post 6, user crontabs are in /var/spool/cron/, at least on RH systems, have look at their contents.

well good. Then to fuel the constructive fire, why can't you just start a cron job immediately, but tell it not to work on anything that is less than 1 year old (or hasn't occurred for 1 year)? As I understand it, this is exactly what you're trying to do, but you're waiting 1 year before you get started. What I'm proposing will start working immediately, but actually not do anything for one year (because everything will be newer than one year).

Of course, I may be missing a part of the picture, but removing a level of indirection will help simplify things for both yourself and the end user. ... and it's easier to find (and stop) a cron job than an at job, at least for basic users.

just wanted to add that. Good luck however you solve it!

"The above"? I don't understand where/what you're referring to. EDIT: And I'm not sure what I need to see on that page.

So is that a dynamic directory, i.e. with different contents when a different user is logged on?

Isn't it inefficient to execute an SQL query that will certainly do nothing? For that matter, isn't it inefficient to check if a year has passed each week for a year? This is the idea behind using 'at'; it's a trade-off of simplicity for efficiency.

Yet avoiding 'at' for the sake of not needing to edit its queue does seem like it might be worth the inefficiency...

RE Inefficient: well, being that a computer's clock does on the order of a few billion ticks per second, using an extra few billion ticks once per week is all but meaningless. Even if the operation takes 10 full seconds to complete, you're still only using ~9 minutes of CPU time per year - which amounts to nothing... much less time than many other deamons take. Same goes for the disk access required. Of course, this is a point for debate & is definitely a design issue; so I suppose there's no right or wrong. However, if it were me, the less support I have to do and the less jumping-through-hoops I have to do, the better. If it were me, I would absolutely take the few minutes or so of bottleneck per year (hell even an hour or a full day of CPU time spread over a year would be fine) to avoid scheduling something a full year from now... especially when that something is another scheduler.

I would say make the timestamp column an index & it should be pretty blazingly fast.

Have fun!

That bit

No it's not dynamic as such - each user has a crontab that is used whether or not they are logged on.

What's so bad about waisting a couple of hundred CPU ctcles a wee - and what overhead does an active AT queue add? I still stick to my view that you should check a datestamp.

OK, I agree with you now, especially since Apple uses 'launchd'... I don't need a third compatibility branch.

What's that have to do with where the user's home directory is? BTW, this is what I was talking about at http://en.wikipedia.org/wiki/Cron:Now I'm trying to understand this:I get the redirection, and that this is supposed to append the quoted characters to the crontab. But I don't find anything to say that 'cat' can write a string to a file. Wouldn't it rather be this?Thanks!