Should I add this to crontab?
(found this hanging in the office)

I fucking HATE it when devs refer to "cronjob" as some kind of fucking webservice and not the actual crontab.

sudo crontab -e
@reboot reboot

sudo poweroff

A ticking time bomb

Ive never really used vim, and therefore not completely understood all the jokes about it..
Yesterday, i somehow ended up editing my crontab with vim.
I have no idea how i managed to quit it, but something worked.

NOTE: No hardware was damaged in the process

The company I work for is currently maintaining some websites under an old (>1.5 years) version of Drupal, which has some well known vulnerabilities.

Yesterday we've found out somebody used them to inject php code into every single .php file on the machine. We've been discussing for hours about how to recover data, upgrade stuff, and maybe switch to something else. I've said jokingly "or we could put a find command in the crontab to sed away the php line they've injected!". Guess what we're doing now on our production servers?

$ crontab -r monthly.irl

The following extra packages will be installed:
pregnancy lib-life lib-fuckyou

Do you wanna continue? [y/n]

I think my server got hacked, yesterday I made a new server on scaleway for the sake of testing I made a user called dev, with password dev. Forgot to change password before I went to bed.

Logged in today to find that load is 5x.x and this (image) in my crontab

Note to self: You are a disgrace, who the hell uses 'dev' as password for ssh on port 22 -_-

Deleted a servers crontab by executing crontab -r instead of crontab -e (typo mistake)
crontab -r deletes the users crontab without any confirmation and, just to top it off, the e key is located right next to r. WTH
At least we have backups.

I was part of a on-call rotation. We had ~800 microsites with decent traffic on this one box, because that's a good idea...

One day the box was experiencing kernel panics and causing core dumps. After exhausting every possiblity I decided it was time to restart the box:

sudo shutdown now

Missed the -r and the box was not accessible remotely. Had to wait for someone at the data center to terminal in.

Downtime was ~2 hours.

This was caused by a crontab that automatically ran apt-get update & apt-get upgrade... Also made by me... None of this should have worked or allowed to be done!

devrant should be aviable in bash also

This was about 3 years ago. I’m on vacation and just getting off the plane, when my boss calls me on his cellphone. Apparently the crontab on our main file upload server had gotten nuked, and he was asking if there were any backups.

A word about this server. I work with video, so this thing is doing about a few gigabits of traffic incoming at any moment. The cron jobs are necessary to move and organize these massive files into a sane scheme for processing. Hundreds of drop folders receiving thousands of files resulting in terabytes of data every single day. Our storage vendor tells us we have the third largest deployment they know about.

No cron jobs mean all of this content is just sitting around piling up. I tell him sorry, try contacting $otherAdmin since he’s more familiar with that system.

A few days later, after the vacation, I come back in. $boss and $otherAdmin have reconstructed the crontab from scratch after an all nighter.

I ask how it got deleted.

$boss was training some people how to set up new customers on this file server, and he told the trainees to open the crontab in read-only mode. One of them ran:

crontab -r

Yes, we back up our crontabs now.

-Writes a function that I'm going to schedule for django.
-works in development.
-adds it to production cron using django-crontab
-not working.
-spends 3 hours editing code, searching for similar problems and reading documentations but find nothing wrong and it's still not working.
-maybe it's django-crontab so I decide to just write a custom management command and call it through cron.
-still not working.
-calls function using what I'm telling cron to do.
-everything works.
-?????????
-adds logs to cron command (sorry for not making it earlier)
-mfw the code is not working because I imported 'patterns' in urls.py which has been deprecated since django 1.8

require "universe"
require "bioDan"

class ProductManager
def initialize(person_type)
@ideas = Universe.import_random_ideas({ mostly_shitty: true, association: person_type })
life_purpose
end

def life_purpose
@ideas.find_each do |idea|
bioDan.interrupt! unless bioDan.bad_mood?
bioDan.queue << idea
end
end
end

ProductManager.create "enthusiastic prick"

%x[crontab -e "0 09 * * * ruby this_script.rb > /dev/null"]

# 😥

Somebody tell me why I shouldn't use systemd timers, as opposed to crontab entries. Because I've been very impressed with them, so far.

Not exactly a data loss, but on server hosting almost all of clients' websites.

$ crontab -e

Except finger slipped and it became -r. *facepalm*

So, I'll explain how my day went with just 2 sentences.

1: Difference between crontab -e and crontab -r.
2: The keys 'E' and 'R' are right next to each other!

If you've understood what just happened, your next question should be "Jason, which environment?"

"PRODUCTION!!!"

So… I prefer nano over other terminal editors (Mainly because I don’t understand how to use others properly) and I wasn’t really aware of the VISUAL and EDITOR environment variables. So on my Arch machine most things would default to vi. Vi to me is like an annoying pop-up that really doesn’t want you to close it (Tho, one thing I did learn eventually was how to close it ). So at some point I quickly wanted to edit crontab as root and I just couldn't manage to get crontab to use nano. So what did I do?

sudo pacman -R vi

ln -s /usr/bin/nano /usr/bin/vi

I symlinked nano to vi and it finally worked. I know that there are probably countless ways this could’ve been done better but in that case I wouldn't have posted it here under wk81 ;)

ZNC shenanigans yesterday...

So, yesterday in the midst a massive heat wave I went ahead, booze in hand, to install myself an IRC bouncer called ZNC. All goes well, it gets its own little container, VPN connection, own user, yada yada yada.. a nice configuration system-wise.

But then comes ZNC. Installed it a few times actually, and failed a fair few times too. Apparently Chrome and Firefox block port 6697 for ZNC's web interface outright. Firefox allows you to override it manually, Chrome flat out refuses to do anything with it. Thank you for this amazing level of protection Google. I didn't notice a thing. Thank you so much for treating me like a goddamn user. You know Google, it felt a lot like those plastic nightmares in electronics, ultrasonic welding, gluing shit in (oh that reminds me of the Nexus 6P, but let's not go there).. Google, you are amazing. Best billion dollar company I've ever seen. Anyway.

So I installed ZNC, moved the client to bouncer connection to port 8080 eventually, and it somewhat worked. Though apparently ZNC in its infinite wisdom does both web interface and IRC itself on the same port. How they do it, no idea. But somehow they do.

And now comes the good part.. configuration of this complete and utter piece of shit, ZNC. So I added my Freenode username, password, yada yada yada.. turns out that ZNC in its infinite wisdom puts the password on the stdout. Reminded me a lot about my ISP sending me my password via postal mail. You know, it's one thing that your application knows the plaintext password, but it's something else entirely to openly share that you do. If anything it tells them that something is seriously wrong but fuck! You don't put passwords on the goddamn stdout!

But it doesn't end there. The default configuration it did for Freenode was a server password. Now, you can usually use 3 ways to authenticate, each with their advantages and disadvantages. These are server password, SASL and NickServ. SASL is widely regarded to be the best option and if it's supported by the IRC server, that's what everyone should use. Server password and NickServ are pretty much fallback.

So, plaintext password, default server password instead of SASL, what else.. oh, yeah. ZNC would be a server, right. Something that runs pretty much forever, 24/7. So you'd probably expect there to be a systemd unit for it... Except, nope, there isn't. The ZNC project recommends that you launch it from the crontab. Let that sink in for a moment.. the fucking crontab. For initializing services. My whole life as a sysadmin was a lie. Cron is now an init system.

Fortunately that's about all I recall to be wrong with this thing. But there's a few things that I really want to tell any greenhorn developers out there... Always look at best practices. Never take shortcuts. The right way is going to be the best way 99% of the time. That way you don't have to go back and fix it. Do your app modularly so that a fix can be done quickly and easily. Store passwords securely and if you can't, let the user know and offer alternatives. Don't put it on the stdout. Always assume that your users will go with default options when in doubt. I love tweaking but defaults should always be sane ones.

One more thing that's mostly a jab. The ZNC software is hosted on a .in domain, which would.. quite honestly.. explain a lot. Is India becoming the next Chinese manufacturers for software? Except that in India the internet access is not restricted despite their civilization perhaps not being fully ready for it yet. India, develop and develop properly. It will take a while but you'll get there. But please don't put atrocities like this into the world. Lastly, I know it's hard and I've been there with my own distribution project too. Accept feedback. It's rough, but it is valuable. Listen to the people that criticize your project.

NOTHING FUCKING WORKS OMG.

I WANT YOU TO RUN EVERY FUCKING 15 MINUTES, IS THAT SO FUCKING HARD? THE ONLY THING THAT'S GOING TO BE HARD AROUND HERE, IS ME!

Geez, all I am trying to do is to run a php script every 15 minutes, and literally every solution I have tried has failed...

Typed crontab - r instead of
crontab - e, gonna be a long weekend to recover crons from log files.

Using git as a backup system

In a crontab:
```
cd $dir
git add .
git commit -m "Auto Commit"
```

Had a customer today that claimed that crontab did not work as it should, and he has proof of that (in form of some very abstract logs).

Well, I guess noone can rely on one of the most fundamental binary in the unix world.

Made this one-liner today:
hostname $(curl nsanamegenerator.com | grep body | sed -e 's/<.*;//g' | sed -e 's/<.*>//g')
and added it to my laptop's crontab...

Just a note to everyone. Please make sure to test your script before putting it on crontab and soft-deleting all backups. They are restored now but seriously...

My selenium script cronjob is not running on the VPS.

I am not sure what's wrong with it

Even the crond service status just shows
the session was opened for the user root
shows the command
the session closed for user root

I tried the tons of solution available but nothing worked

I am using Ubuntu 16.04 with LXDE

I want to understand Linux services better. Most of the time if I want to run a process in the background, I just use nohup and &

And put the commands in either init.d or crontab.

But lately I've seen some more complex scripts where it's called like logstash start/stop which does a free things including recording the PID somewhere?

In Linux terms it seems to be called starting a daemon. But what's the difference, benefit to all this complexity?

So I just ran crontab -r while thinking that I should be careful not to run it when trying to run crontab -e FML!