How to make a command run everyday at a specific time?
How to make a command run everyday at a specific time?
I am on Mint XFCE and Redshift is just so inconsistent and I have tried its forks, also inconsistent. So instead I have been using sct in the terminal to adjust the temperature, and have set a command that resets it back to normal every time that I log on. However, I was wondering if there is a way to make it so that "sct 2750" runs every day at 10 pm or during a specific period of time.
Edit: I figured out the solution which was to create a crontab with the following line in it: 0 22 * * * env DISPLAY=:0 XAUTHORITY=$HOME/.Xauthority /usr/bin/sct 2750
You're viewing a single thread.
People suggesting legacy methods like cron, but the only valid answer for modern Linux distributions is to use a systemd timer in userspace.
You just set up a service (what should be done and how do you want it to be done) and a timer (when should it be done).
https://gist.github.com/oprypin/0f0c3479ab53e00988b52919e5d7c144
Which is a lot more difficult in every aspect than just throwing a single line on crontab and calling it a day.
a lot more difficult in every aspect
Perfect summary of systemd
At the same time you get a lot more benefits doing so. You also don't need to install additional software just to run a background task every X time units.
And if you need to learn something, just learn the current state if the art.
I don't know any distro that ships without cron installed out of the box. Maybe some bare bones minimal distro but I assume that OP isn't using that or he would not need to ask this question.
I don't agree with this statement, personally. People who aren't familiar with cron will see magic numbers and magic characters. It's also possible to have friction getting the environment set up correctly for the program being called by cron.
systemd timers use exact phrases in its configuration like "daily." You can also name the timer, start and stop the timer, view logs specifically for that timer, etc. Plus, it just calls a service file, which again is much simpler than other options like System V. You can run multiple commands in order, set an environment, use a user, jail the commands, etc.
Any of these things done "the old way" have been obscure and difficult. When was the last time you thought about a runlevel? The timer configs aren't one-liners, but it's because it's packed loads of features and it's human-readable. Plus, anything you do surrounding the cron job is also obscure, in my opinion.
Plus, cron jobs, if you choose to use them, are performed by systemd compatibility code, anyway.
Cron may be old but I don't think it's "legacy" or invalid. There's plenty of perfectly good, modern implementations. The interface is well established, and it's quite simple to schedule something and check it. What's more, Cron works on new Linux systems, older non-systemd ones, and BSD and others. If all you need is a command run on a schedule, then Cron is a great tool for the job.
Systemd services and timers require you to read quite a bit more documentation to understand what you're doing. But of course you get more power and flexibility as a result.
Systemd services and timers require you to read quite a bit more documentation to understand what you’re doing. But of course you get more power and flexibility as a result.
Yes. There is simply no reason not to make it state-of-the-art from the beginning on. You get proper logging, proper error handling, better scheduling options and you most likely don't even need to set up additional software because systemd (and thus systemd timers) are default in pretty much all common Linux distributions (except some niche ones) since 10+ years.
"simply no reason"?
What about ease of use, simplicity, faster to quickly setup, backwards compatibility, and "crobtab is where everyone will look at when looking for a scheduled task"?
If systemd was implemented right, it would create the systemd files and autoconfigure default tasks by reading the crontab, for backwards compatibility.
What about ease of use, simplicity, faster to quickly setup, backwards compatibility,
The syntax of systemd timers is MUCH easier to read for newbies (and everyone else, really) as it uses words instead the placement of the characters on the line to convey meaning. If you can't remember or don't know the syntax well you can still understand a systemd timer, but that is much hard for the crontab. Granted, crontab uses fewer characters, but if you only set up either once in a blue moon you'll need the docs to write either for a long time. And is backwards compatibility really an issue with either one? All major desktop and server distros use systemd, and has for a while. Fedora doesn't even include a Cron by default anymore.
"crobtab is where everyone will look at when looking for a scheduled task"?
If it was a distro release from the last decade I'd definitely start by checking the systemd timers, rather than the crontab.
If systemd was implemented right, it would create the systemd files and autoconfigure default tasks by reading the crontab, for backwards compatibility.
You can to totally do this, using this systemd generator.
If you can’t remember or don’t know the syntax well you can still understand a systemd timer, but that is much hard for the crontab.
I will agree that it is easier to read a timer than a Cron entry, especially if you've seen neither of them before.
Granted, crontab uses fewer characters, but if you only set up either once in a blue moon you’ll need the docs to write either for a long time.
This is where I disagree. I very rarely setup a Cron job, but when I do, I don't need to look anywhere for docs. I run
crontab -eand the first line of the editor contains a comment which annotates each column of the Cron entry (minute, hour, dom, mon, dow). All that's left is to put in the matching expressions, and paste my command.Compare that to creating a new timer, where I need to Google a template
.serviceand.timerfile, and then figure out what to put in what fields from the docs. That's probably available in the manual pages, but I don't know which one. It's just not worth it unless I need the extra power from systemd.This is from somebody who has several systemd timers and also a few Cron jobs. I'm not a hater, just a person choosing the best and easiest choice for the job.
You seem to have fallen foul of all the SystemD haters in the voting, when this is the best answer. OP's question was about doing one thing on a timer and a very similar thing on login; SystemD can achieve both of these in one place with proper logging and status displays, whereas Cron cannot.
Most of the things that you'd want to run on a timer have additional dependencies (I'd like to snapshot the database if the database is running; I'd like to backup up my files to a remote server if the network is up) which as easy to express in SystemD files as anything else it can do. Might as well learn to use the most versatile and powerful tool if you're going to learn anything. Admittedly, I don't like its syntax, but it achieves this kind of thing perfectly.
An additional thing is that cronie/cron has no idea about an user desktop session out of the box while systemd user scripts do
OP edited this solution which needed a special env variable DISPLAY
this might be common knowledge but it certainly is not for a beginner
Why is cron not a good solution?
I didn't say it is not a good solution. It's a legacy solution replaced by systemd timers.
With systemd timers you're entirely more flexible and timers run much more reliable. You also get proper logging and you cleanly separate program execution and scheduling of program execution. And since timers aren't crammed all in one file line-by-line you can independently version them using Git or backup individual timer configurations.
If you don't care for that and don't really care if a job gets executed reliably and don't want to specify precisely when (on startup, on shutdown, specific time, repeatedly, etc.) a program is executed, just go with cron - you might need to install a cron daemon and set up the needed service in systemd first.