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.
My servers are up to date and there is not a single Linux distro that has removed cron or marked it for removal yet. Probably will stay that way for a long time.
So I attempted to run a crontab and for whatever reason it does not do anything. What I put was * * * * * /usr/bin/sct 2750 after sudo crontab -e just to see if it even runs but it does not do anything. I rewrote and added multiple crontabs but no results. Any help would be appreciated.
For the "schedule expression" (the * * * * * part), try https://crontab.guru/. Some distributions have shortcut expressions like @hourly or @daily so you don't have to type * */1 * * * etc.
The crontab generally has a header that shows the columns, but if not, they're: m h dom mon dow command.
From * * * * * /usr/bin/sct 2750 I'm guessing you want to run every minute. If that's the case, as another commented pointed out, try */1 * * * * /usr/bin/sct 2750, meaning every 1 minute.
OK... So, just to test, edit your crontab and run a basic command:
*/1 * * * * date >> ~/date.log
this will append the current date/time once a minute (*/1) to a file in your home dir. You can check if it works with cat ~/date.log
If that works, then try again with your command. I see you used the full path to it, that's a good thing. Also, what does that command do if you run it manually?
To run the command at 10 PM every day, you should have it like this:
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 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.
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.
@addie@Dirk I think you're spot on. SystemD timers are mildly more inconvenient to create than cron jobs, but massively more convenient to maintain and work with for real.
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.
For cron write 'man cron' into your terminal and read the manpage docs on how to use cron. As already suggested 'crontab -e' is the command you need, but a quick look in the docs explains you how it actually works.
I don't give you direct answers simply because I want you to learn Linux by yourself and enjoy the benefits of it :)
Since you only need to run a single command as a user open terminal and give command 'crontab -e'. If you haven't set an editor it'll ask for one, pick nano.
The syntax for crontab is like this (man 5 crontab will show it on your system as well):
field allowed values
----- --------------
minute 0–59
hour 0–23
day of month 1–31
month 1–12 (or names, see below)
day of week 0–7 (0 or 7 is Sun, or use names)
command to run with full path
So, in your case put in this line:
0 10 * * * /usr/bin/sct 2750
I'm not sure if sct is really at that path and I don't have that installed, so verify that first (run 'which sct'). Save the file and exit editor (ctrl+o, ctrl+x on nano). That's it. However, I don't quarantee results with that, since X with environment variables and all may cause issues, but if that's the case I'm sure this community can help with that as well.
While cron will do the job just fine, if you want to be a bit more fancy and tie it to sunrise/sunset times, you can do that using at and sunwait. I have a similar setup, but it changes my monitor's brightness.
You could use either systemd timers or anacron, which is a version of cron designed for laptops and machines that are not powered on 24/7 like servers.