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

    • IsoKiero@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      28
      arrow-down
      3
      ·
      1 year ago

      Which is a lot more difficult in every aspect than just throwing a single line on crontab and calling it a day.

      • 𝘋𝘪𝘳𝘬@lemmy.ml
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        5
        ·
        1 year ago

        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.

        • Maestro@kbin.social
          link
          fedilink
          arrow-up
          5
          arrow-down
          2
          ·
          1 year ago

          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.

      • Synthead@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        1 year ago

        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.

    • the_sisko@startrek.website
      link
      fedilink
      English
      arrow-up
      20
      arrow-down
      3
      ·
      1 year ago

      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.

      • 𝘋𝘪𝘳𝘬@lemmy.ml
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        6
        ·
        1 year ago

        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.

        • jsveiga@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          9
          arrow-down
          1
          ·
          1 year ago

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

          • Ullebe1@lemmy.ml
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            2
            ·
            1 year ago

            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.

            • the_sisko@startrek.website
              link
              fedilink
              English
              arrow-up
              2
              ·
              edit-2
              1 year ago

              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 -e and 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 .service and .timer file, 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.

    • addie@feddit.uk
      link
      fedilink
      English
      arrow-up
      14
      arrow-down
      1
      ·
      1 year ago

      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.

      • EddyBot@feddit.de
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        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

    • jsveiga@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      14
      arrow-down
      2
      ·
      1 year ago

      Honest question: Why is that the only valid question, if crontab works and is much, much simpler to use?

      • Last@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        arrow-down
        5
        ·
        edit-2
        1 year ago

        He might be a new linux user. There are 10 ways to do every task, and all are vaild if they work for you.

        I don’t even use systemd, so I guess Gentoo isn’t modern. He even mentions userspace, like OP is going to edit his kernel or something.

        Enjoy the helpdesk, @Dirk

      • 𝘋𝘪𝘳𝘬@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        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.