crontab - how not to

[Diputs]

Found this the other day, as a Crontab job, I can't understand why people write these kind of commands.

10 22 * * 4 cd /some/directory ; find . -type f -name '*log' -mtime +15 -exec rm {}

I think this is basically looking for troubles. Do you agree or not ?

 

[MikeRocor]

The only thing I would find hazardous about that is my own lack of expertise with the find command. At a glance, it looks like it will, at 10:10 PM every Thursday, remove any log file under /some/directory/ that hasn't been updated in 15 or more days.

If that's really what is wanted, no problem, I guess.

Not sure why the explicit cd instead of using

10 22 * * 4 find /some/directory -type f -name '*log' -mtime +15 -exec rm {}

I've bookmarked this crontab scheduling tool for those of us who don't fiddle with such things often enough to remember how they go: crontab guru

 

[Vimmer]

That command is used to remove log files dated for particular times, at specific times. I basically just use "@reboot" for my cronjobs (im not a system admin, beyond my computer)

 

[osprey]

Found this the other day, as a Crontab job, I can't understand why people write these kind of commands.

10 22 * * 4 cd /some/directory ; find . -type f -name '*log' -mtime +15 -exec rm {}

I think this is basically looking for troubles. Do you agree or not ?

That particular command will not run because it lacks the syntax to let the find command know when it stops. It needs "\;" at the end of it to run.

In general the calling of a script by cron is more usual because it's more convenient if the user has cause to alter the desired outcome. They only need to work with the script. Overall though, with a systemd system, using the systemd timers has more flexibility and is much finer grained in the controlling options it provides than cron.

As to why one would run a command directly as shown in the example, one can only speculate, but my guess would be that it was related to the experience of the user who set it.

 

[JasKinasis]

The only thing I would find hazardous about that is my own lack of expertise with the find command. At a glance, it looks like it will, at 10:10 PM every Thursday, remove any log file under /some/directory/ that hasn't been updated in 15 or more days.

If that's really what is wanted, no problem, I guess.

Not sure why the explicit cd instead of using

10 22 * * 4 find /some/directory -type f -name '*log' -mtime +15 -exec rm {}

I've bookmarked this crontab scheduling tool for those of us who don't fiddle with such things often enough to remember how they go: crontab guru

I’d replace the -exec rm {} part with find’s -delete option too.

 

[MikeRocor]

See... that's what I meant about "my own lack of expertise with the find command".

I used to actually go so far as to

find . |grep targetfile.txt

because I didn't remember the syntax for find. I actually did that in a job interview and the guy looking over my shoulder never batted an eye (and I got the job).

 

[Diputs]

The only thing I would find hazardous about that is my own lack of expertise with the find command. At a glance, it looks like it will, at 10:10 PM every Thursday, remove any log file under /some/directory/ that hasn't been updated in 15 or more days.

If that's really what is wanted, no problem, I guess.

Not sure why the explicit cd instead of using

10 22 * * 4 find /some/directory -type f -name '*log' -mtime +15 -exec rm {}

I've bookmarked this crontab scheduling tool for those of us who don't fiddle with such things often enough to remember how they go: crontab guru

Yes, it's supposed to remove files

 

[Diputs]

That command is used to remove log files dated for particular times, at specific times. I basically just use "@reboot" for my cronjobs (im not a system admin, beyond my computer)

Haha, I didn't even know that existed - Thanks

 

[Diputs]

That particular command will not run because it lacks the syntax to let the find command know when it stops. It needs "\;" at the end of it to run.

In general the calling of a script by cron is more usual because it's more convenient if the user has cause to alter the desired outcome. They only need to work with the script. Overall though, with a systemd system, using the systemd timers has more flexibility and is much finer grained in the controlling options it provides than cron.

As to why one would run a command directly as shown in the example, one can only speculate, but my guess would be that it was related to the experience of the user who set it.

That's a valid point as well, I don't like long commands in Crontab because they make things unclear,
but also, every time you want to change the command, you must modify Crontab ...
I can tell that the person writing this, HATES to write scripts. The person has difficulty enough with command line commands, so it may be better that no script was used, it would be bad anyway. Still, there's many errors in this command indeed, the lack of " \; " I didn't even thought of.
I thought that : if existing in Crontab, it would work. Turns out it doesn't. Well, just another thing wrong with this.
Note also that no redirection was used, and also that I still don't consider as the killer problem.

 

[Diputs]

See... that's what I meant about "my own lack of expertise with the find command".

I used to actually go so far as to

find . |grep targetfile.txt

because I didn't remember the syntax for find. I actually did that in a job interview and the guy looking over my shoulder never batted an eye (and I got the job).

That would have been fun I guess, I mean, it depends ... Maybe he was learning from you !

 

[Diputs]

I'm surprised nobody mentioned what I think is the elephant in the room ... I guess it proves that people are different !

But, what if /some/directory doeesn't exist, or you can't navigate to it ?

It's not far fetched either, it's not like /usr/bin is missing or so.

 

[MikeRocor]

I'm surprised nobody mentioned what I think is the elephant in the room ... I guess it proves that people are different !

But, what if /some/directory doeesn't exist, or you can't navigate to it ?

It's not far fetched either, it's not like /usr/bin is missing or so.

Oof! I guess -that- would be the difference between

10 22 * * 4 cd /some/directory ; find . -type f -name '*log' -mtime +15 -exec rm {}

and

10 22 * * 4 find /some/directory -type f -name '*log' -mtime +15 -exec rm {}

 

[MikeRocor]

That would have been fun I guess, I mean, it depends ... Maybe he was learning from you !

Another guy who was hired the next day for the same position (there were about a dozen openings) seemed like he might have some interesting viewpoints, so I asked him what linux he used on his personal machine(s). He said, "I've never used linux in my life before two days ago." TBH, the job didn't actually require "linux administration" skills per se, though it did involve having root access to remote computers and not doing dumb stuff to them.

 

[Diputs]

Oof! I guess -that- would be the difference between

10 22 * * 4 cd /some/directory ; find . -type f -name '*log' -mtime +15 -exec rm {}

and

10 22 * * 4 find /some/directory -type f -name '*log' -mtime +15 -exec rm {}

Yeah, it may look alike from far, but it's different. The semicolon is a small but extremely important character