• Arthur Besse@lemmy.ml
    link
    fedilink
    English
    arrow-up
    15
    ·
    edit-2
    24 days ago
    $ systemd-analyze calendar tomorrow
    Failed to parse calendar specification 'tomorrow': Invalid argument
    Hint: this expression is a valid timestamp. Use 'systemd-analyze timestamp "tomorrow"' instead?
    $ systemd-analyze timestamp tuesday
    Failed to parse "tuesday": Invalid argument
    Hint: this expression is a valid calendar specification. Use 'systemd-analyze calendar "tuesday"' instead?
    

    ಠ_ಠ

    $ for day in Mon Tue Wed Thu Fri Sat Sun; do TZ=UTC systemd-analyze calendar "$day 02-29"|tail -2; done
        Next elapse: Mon 2044-02-29 00:00:00 UTC
           From now: 19 years 4 months left
        Next elapse: Tue 2028-02-29 00:00:00 UTC
           From now: 3 years 4 months left
        Next elapse: Wed 2040-02-29 00:00:00 UTC
           From now: 15 years 4 months left
        Next elapse: Thu 2052-02-29 00:00:00 UTC
           From now: 27 years 4 months left
        Next elapse: Fri 2036-02-29 00:00:00 UTC
           From now: 11 years 4 months left
        Next elapse: Sat 2048-02-29 00:00:00 UTC
           From now: 23 years 4 months left
        Next elapse: Sun 2032-02-29 00:00:00 UTC
           From now: 7 years 4 months left
    

    still image from "Zach Galifianakis Math" gif, with Zach looking contemplative with math notation floating in front of his face

    (It checks out.)

    Surprisingly its calendar specification parser actually allows for 31 days in every month:

    $ TZ=UTC systemd-analyze calendar '02-29' && echo OK || echo not OK
      Original form: 02-29
    Normalized form: *-02-29 00:00:00
        Next elapse: Tue 2028-02-29 00:00:00 UTC
           From now: 3 years 4 months left
    OK
    $ TZ=UTC systemd-analyze calendar '02-30' && echo OK || echo not OK
      Original form: 02-30
    Normalized form: *-02-30 00:00:00
        Next elapse: never           
    OK
    $ TZ=UTC systemd-analyze calendar '02-31' && echo OK || echo not OK
      Original form: 02-31
    Normalized form: *-02-31 00:00:00
        Next elapse: never           
    OK
    $ TZ=UTC systemd-analyze calendar '02-32' && echo OK || echo not OK
    Failed to parse calendar specification '02-32': Invalid argument
    not OK
    
  • mlg@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    24 days ago

    Systemd ignored my calendar override for the builtin raid scanner, so every week my server would chug to a halt to scan the entire array.

    In true systemd fashion, the documentation could not explain this behavior, so I had to make a full copy override instead of a merge override because reasons.

  • peopleproblems@lemmy.world
    link
    fedilink
    arrow-up
    31
    ·
    25 days ago

    Well. I mean, that’s pretty cool. I don’t think I would have ever guess that was an actual function from systemd but here we are

  • umbraroze@lemmy.world
    link
    fedilink
    arrow-up
    24
    ·
    23 days ago

    Well, systemd developers made one of the classic blunders a software developer can do: make a program that has to deal with time and dates. Every time I have to deal with timestamps I’m like “oh shit, here we go again”.

    Anyway, as I understood it the reason this is in systemd is because they wanted to replace cron, and it’s fine by me because cron has it’s own brain-hurt. (The cron syntax is something that always makes me squint real hard for a while.)

    • flying_sheep@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      23 days ago

      Yeah and they actually added some usability in the form of that utility helping you debug what you’re doing. Pretty nice!

    • Phoenixz@lemmy.ca
      link
      fedilink
      arrow-up
      4
      arrow-down
      4
      ·
      23 days ago

      I’m sorry but Cron is really easy, of all systems.

      Try using systemd with an ssh server that you want to have running on a non standard port. On non systemd it’s a 15 second ordeal while on systemd I don’t even know where to start, I pushed it out of my memories. It’s something something create files here, restart demons there, removing other files, it is WAY WAY over complicated

      • offspec@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        23 days ago

        What do you mean? You literally just change the /etc/sshd config to point at a different port do you not?

        • Phoenixz@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          17 days ago

          Oh yeah, without systemd that’s all there is to it. With systemd, however, port management is taken out of the ssh config and is done how it was decades ago

      • umbraroze@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        23 days ago

        Well cron is “really easy” as long as your requirements are really easy too.

        Run a task at specific hour or minute or weekday or whatever? Easy peasy.

        Run a task at complex intervals? What the fuck is this syntax. How do I get it right even. Guess I’ll come back next week and see if it ran correctly.

        Actually have to look at the calendar to schedule this stuff? Oh lawd here come the hacks, they’re so wide, they’re coming

        Run a task at, say, granularity of seconds? Of course it’s not supported, who would ever need that, if you really need that just do an evil janky shellscript hack

  • mogoh@lemmy.ml
    link
    fedilink
    arrow-up
    98
    ·
    25 days ago

    Usually such things have a simple explanation. systemd does a lot with time and date, for example scheduling tasks. It’s quite obvious that it has this capabilities, when you think about it.

    • m4m4m4m4@lemmy.world
      link
      fedilink
      arrow-up
      54
      arrow-down
      8
      ·
      25 days ago

      Usually such things have a simple explanation. systemd does a lot with time and date, for example scheduling tasks. It’s quite obvious that it has this capabilities, when you think about it.

      FTFY

      • Phoenixz@lemmy.ca
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        24 days ago

        Too much

        But that has been a complaint for 10 years and it’s only gotten worse

        I wouldn’t mind systemd if it weren’t for the fact that it was to be a startup system that promised to make everything easier and faster to startup yet managing systemd is a drag at best, and of it did one thing it’s making my systems boot up like mud

        • Kusimulkku@lemm.ee
          link
          fedilink
          arrow-up
          3
          arrow-down
          1
          ·
          24 days ago

          I feel like the glued together collection of scripts was way worse to manage than systemd.

          • Phoenixz@lemmy.ca
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            23 days ago

            Is it? It was always super easy to get anything done and with systems it suddenly got factors more complicated. Port assignment was super easy to do, note the past tense. It now requires systemd and instead of a 15 second config file change and service restart I now need to create and delete files, restart multiple services, God knows what in systems.

            Simply put: why? If you make an alternative solution AT LEAST it shouldn’t become way more over complicated to get basic tasks done

            • Kusimulkku@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              23 days ago

              I definitely think so. Init was a mess of bash scripts and concurrency and whatnot was a problem. Making a script to start a service was very dependent on the distro, their specific decisions and whatnot. Systemd services and timers make things very easy and they have great tools to manage those. And now it’s basically the same on every distro.

    • bricked@feddit.org
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      6
      ·
      24 days ago

      I thought the same, but didn’t we already have things like chron syntax for this? Systemd didn’t have to build its own library.

        • bricked@feddit.org
          link
          fedilink
          English
          arrow-up
          8
          arrow-down
          1
          ·
          24 days ago

          Aight, didn’t know that. I cannot yet imagine any scheduled task that would require anything more advanced than cron (or a similar standalone syntax), but I’ll just trust you with that one.

  • kameecoding@lemmy.world
    link
    fedilink
    arrow-up
    20
    ·
    24 days ago

    It is literally happening this year.

    24th is Tuesday. 1st of January is Wednesday and as a bonus Jan 6 is also a holiday in my country and that’s Monday.

    So from dec 22 to jan 6 i can be home by using just 6 days off

    • Ullallulloo@civilloquy.com
      link
      fedilink
      arrow-up
      3
      ·
      24 days ago

      The 25th is a Wednesday, not a Tuesday like he was wanting. Tuesday is nice because you get a four-day weekend without using any days off. (Though, usually you’d get the next off if it was a Monday or Sunday or whatever.) I think the best is Friday or Monday because then New Year’s gives you a three-day weekend too.

      • kameecoding@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        24 days ago

        to me it doesn’t matter tbh, as long as the 24th is somewhere monday-wednesday, that means days off that week, we get 24,25,26 off.

  • Matt@lemmy.ml
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    23 days ago

    Just write your own initialization system in bash. It is more reliable and less bloated.

    • exu@feditown.com
      link
      fedilink
      English
      arrow-up
      55
      arrow-down
      1
      ·
      24 days ago

      You need a calendar and time handling anyways for logging purposes and to set timers correctly. It’s likely not that much extra work exposing that functionality.

      • Kusimulkku@lemm.ee
        link
        fedilink
        arrow-up
        20
        arrow-down
        3
        ·
        24 days ago

        No, UNIX philosophy demands that every single one of those things is one or more separate things and that half of them are poorly or not at all maintained. Just like God intended.

        • DrDystopia@lemy.lol
          link
          fedilink
          arrow-up
          5
          arrow-down
          6
          ·
          24 days ago

          Finding the next super holiday is a core system feature I could survive without. 🎉

          • Kusimulkku@lemm.ee
            link
            fedilink
            arrow-up
            8
            arrow-down
            1
            ·
            edit-2
            24 days ago

            Well, date time stuff for a system working with timers and scheduling actions might be pretty useful…