Crontab typo
-
Boss likes to maintain his "infrastructure" using PHP scripts orchestrated through crontab. He has hundreds of them, running all the time, shuffling data between MySQL databases, API-s and FTP-s, all over the internet.
We were working on some performance problems on the central server. We needed to shut down some of his crons.
He tried to type
crontab -e
.He fat-fingered "e" and typed "r".
There was no
crontab=crontab -i
alias.And, of course, there is no backup.
-
PHP scripts orchestrated through crontab
-
And, of course, there is no backup.
Perhaps that's nature's way of telling him to
slow downmend his ways.
-
And, of course, there is no backup.
WTF!
I'm going to leave the "CLI deletes all your shit if you fat-finger a single letter" complaining because you all know that, but why the FUCK was there no backup?
-
Is there documentation for what was lost? Then you can rebuild it not as the terrible mess you described.
-
Did you get the part with crontab running PHP scripts? This is not exactly a sophisticated operation.
I'm sure he has MySQL dumps, and the software is probably
in version controlin a folder on his laptop, but crons will likely have to be rewritten from logs.
-
crontab backup is probably
-R
...
-
Is there documentation for what was lost? Then you can rebuild it not as the terrible mess you described.
HA! Documentation.
He might be able to get cron logs, as a reminder of what was running before the typo.
-
Boss likes to maintain his "infrastructure" using PHP scripts orchestrated through crontab. He has hundreds of them, running all the time, shuffling data between MySQL databases, API-s and FTP-s, all over the internet.
:barf:
i think even @arantor would have trouble swallowing that one
-
He did it! It's a paste!
-
-
-
Trolling, apparently.
-
-
Well, with a little C knowledge you might submit a patch to avoid this in crontab and get some dev-cred.
-
Well, with a little C knowledge you might submit a patch to avoid this in crontab and get some dev-cred.
And then wait 10 years for the average linux server to get it.
-
Got any stats on that? I've seen my share of outdated Linux servers, but not that old... OTOH I did get to work with some Solaris and HPUX ones.
-
Got any stats on that? I've seen my share of outdated Linux servers, but not that old... OTOH I did get to work with some Solaris and HPUX ones.
I'm still getting a lot of Centos 5-s which are like 8 years old now.
-
Close, but no cigar.
-
I can... we do it on Windows for bonus points.
-
I can... we do it on Windows for bonus points.
Don't you just hate it when you want to click "Edit" in the Task Scheduler, but accidentally click "Delete all tasks" and then have to create everything from scratch?
-
...and this is why you don't use crontab -e.
Since you cut out the first line, the last optional argument to crontab is a file name. You can use it to replace the current crontab (or another user's crontab with
-u
) with the contents of the file.
-
Undo would not have been very difficult to implement I guess. But crontab likes to discriminate against the fat-fingered.
I reckon the responsible have been fired. Uh oh
-
I can... we do it on Windows for bonus points.
Using CRON?
Or Task Scheduler?
Because in any universe where the latter exists, the former most definitely should not.
-
I can... we do it on Windows for bonus points.
this needs its own writeup. for academic purposes of course
-
cron on Windows implemented with Perl and then hosted from SourceForge. What could possibly go wrong?
-
We need to add one of the following to complete it:
- Dwarf Fortress
- my BIT interpreter
- lojban
- large(r than the screen) screenshots
-
More the fact we run an entire fleet of infrastructure on PHP on Windows. Yes, it's Task Scheduler, but I forgot you were a pendant that needed it spelled out to you and couldn't take a little bit of thought to realise what I was getting at...
-
I've never fat fingered -r, but whoever added that without a -f (force) was an ass.
Anything in /var/log about what ran the past X days? Probably can't reconstruct the schedule perfectly but that is a lesson to learn.
I think I have 2 entries in my crontab that are doing something of value. Not worth backing up as they just run a script (not complicated to remember).
-
@Arantor said:
I can... we do it on Windows for bonus points.
this needs its own writeup. for academic purposes of course
Imagine a script to run half a million queries to build a report set that gets shoved through PHPExcel. Rerun every hour. Be amazed at server performance.
-
there has to be more WTF in there than that.
:-D
-
I kind of avoided the subject because the "cron jobs" are pretty tied to what we do and if you'll notice from the Lounge thread, I carefully avoided the subject of what I do on the basis that if you knew what my company did, there's a fair chance you could identify the company.
-
The biggest WTF is not the -r option, but the -i option.
It's a safety against this thing happening... but you have to explicitly enable it every time? This doesn't even begin to make sense .
You know those machines where you have to hold two separate buttons for them to work so you can't get your hands caught in them? It's like adding a third button that you also have to hold if you want the safety mechanism to work.
-
The biggest WTF is not the -r option, but the -i option.
It's a safety against this thing happening... but you have to explicitly enable it every time? This doesn't even begin to make sense .
You know those machines where you have to hold two separate buttons for them to work so you can't get your hands caught in them? It's like adding a third button that you also have to hold if you want the safety mechanism to work.
It's having to hold the second safety button to activate the safety at all, otherwise it always happens. Lean your elbow on the main button and the plant blows up. SIMPSON!
I understand dry run options, but destructive options might need one last sanity check. Command lines tend to think about ease of use over failure modes, though.
-
And of course, you wouldn't need any confirmation at all if it was something like "--delete-crontab" instead of "-r".
Well, with a little C knowledge you might submit a patch to avoid this in crontab and get some dev-cred.
But what about backward compatibility? Think of all the scripts that call crontab -r and expect it to work.Fun fact: my hard drive was almost trashed once because some ntfsresize command added a confirmation prompt, and GParted didn't know how to handle it.
-
Command lines tend to think about ease of
useimplementation over failure modesCommand lines tend to think about ease of
usedestruction over failure modes
FTFY, although I can't choose which version is better. Maybe both?
-
-
FTFY, although I can't choose which version is better. Maybe both?
I think I meant to say "ease of creation." One letter SURE BEATS a whole long name.
-
I've seen people mistype
crontab -e
ascrontab e
.That will make crontab look for a file called
e
to load the crons from.
If crontab doesn't find a file callede
then crontab won't give you a FILE_NOT_FOUND error.
Instead crontab will delete your existing crons because that's obviously what you wanted.
-
I've seen people mistype crontab -e as crontab e.
That will make crontab look for a file called e to load the crons from.If crontab doesn't find a file called e then crontab won't give you a FILE_NOT_FOUND error.Instead crontab will delete your existing crons because that's obviously what you wanted.
No repro.
$ echo '* * * * * echo "test" >> /tmp/crontest' | crontab $ crontab -l * * * * * echo "test" >> /tmp/crontest $ crontab e e: No such file or directory $ crontab -l * * * * * echo "test" >> /tmp/crontest
-
I guess they've fixed it now or it only happens on some distros.
-
Introducing
getopt_long
, courtesy GNU. The single-letter versions will remain forever due to backwards compatibility though.
-
Introducing
getopt_long
, courtesy GNU. The single-letter versions will remain forever due to backwards compatibility though.Especially since new software keeps reusing single-letters, mostly because old software did.
-
Imagine if the UI was different to the API. Then you could change the commands used by humans working with the software, while other software hooking into it was still presented with the same interface.
Someone should invent something like that
-
Imagine if the UI was different to the API. Then you could change the commands used by humans working with the software, while other software hooking into it was still presented with the same interface.
Someone should invent something like that
That's a good idea. They could call it something like an interface, even. They could have command-line versions, application program versions, and even user versions, the possibilities are endless.
-
And if all programs using that API explicitly stated the version they are targeting, changing its behavior without breaking backwards compatibility would be a breeze.
-
Fun fact: my hard drive was almost trashed once because some ntfsresize command added a confirmation prompt, and GParted didn't know how to handle it.
If only there was a way to link into some common library that both the CLI command and GParted could directly access, instead of going through the shell...man programmers should really come up with a system for this.
EDT: 'd apparently.
-
Command lines tend to think about ease of use
I know somebody who would vehemently disagree with that statement.
-
Y'know, that link to Paul Vixie's Wiki page reminded me of my first encounter with editing crontabs. It was 1995, and I was working on an installation of Slackware 3.1.
And I looked up the manpage for crontab(5), which helpfully told me that the format of a GNU crontab was like the format of vixiecron's crontab.
(Word to the unwise: this is not helpful. Someone who knows vixiecron probably isn't going to read this manpage, and someone who doesn't isn't helped by knowing that this crontab is like some other crontab he has never heard of.)
-
(Word to the unwise: this is not helpful. Someone who knows vixiecron probably isn't going to read this manpage, and someone who doesn't isn't helped by knowing that this crontab is like some other crontab he has never heard of.)
Reminds me of the developer at a previous job who made a tool that, among other things, computed the MD5 hash of a file. In his documentation, he had something along the lines of "this works like the Linux MD5".
This was in a place with an all Microsoft stack, he was just a Linux guy to whom that was more than enough documentation. Didn't matter that it was useless to everyone else