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.

You mean running systemd timers? Yes, they are great, but for a beginner I think understanding crontabs is still better.

Also, who said crontabs are deprecated? Do you have a source for that?

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:

0 22 * * * /usr/bin/sct 2750

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 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.

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.

@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.

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

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.

There's no need to be sorry for being noob. I also recognized that from your original post.

Fast and short bash-scripting course with actually useful tasks:

https://www.youtube.com/playlist?list=PLT98CRl2KxKGj-VKtApD8-zCqSaN2mD4w

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.