Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
sudo in Windows.Please report posts and comments that break these rules!
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.)
Oh fuck. I'll use this from now on. Except for if I won't use it next week. Then I'll forget about it because my memory is a damn sieve.
Just take the next step and make a text file you dump all these commands into and then forget about in a week. When you randomly stumble across it years from now you’ll be able to say “wow, I could have used this 10 months ago if I remembered it existed!”
I make a separate text file per command so I can search them!
Which I dont.
I usually print these out and put them in a safe deposit box at a bank so I never lose them
Use a systemd timer to send yourself a reminder. Discoverd them recently myself and honestly liking them more than cron.
systemd is a great operating system, it just lacks a decent text editor.
Good thing it's editor agnostic so everybody can do the right thing in the end and choose nano
Funny way to misspell vim
alias systemd-texted=micro
me: systemd is not that bloated
systemd:
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.
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.
Try scheduling a cron tab job to run a task on dates defined that way.
I think this is for setting date oriented timers
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.
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
This is basically just a way nicer, more flexible cron syntax being dressed up as something ridiculous. There are legitimate reasons for wanting something like this, like running some sort of resource heavy disk optimization the first Friday evening of every month or something.
This plays some kind of role in the debate of systemd being good or not. I'm not sure if goes in the good column or the bad column, but I know it goes into a column.
I am typically in the group saying "systemd is overlarge with too many responsibilities" but this capability makes perfect sense for its job running services. Probably the good column.
In the UK, if Christmas or New Year falls on a weekend, a seperate equivalent holiday is made during the week to compensate.
Wait, do other countries not do this? So if a public holiday falls on a Saturday it doesn't get pushed to Monday?
Germany doesn't do this, but the minimum, when all holidays fall on the worst possible days, is more than the number of holidays in the UK.
Don't do that in Norway either - just bad luck if the holidays happen to land on a weekend. On the other hand, we have five weeks of paid vacation, and holidays are not counted into those, I'm not sure how that's done in other countries?
but the UK has the fewest public holidays in Europe. In Germany we have 9-13 but don't get a day off if a public holiday is on a weekend. And we have a minimum of 20/24 days of holiday on top
Finally we can put all the controversy around systemd to rest.
systemd is the future, and the future has been here for over a decade and yet old Unix and BSD purists still cry about it
I have one simple thing to say to the downvoters: I am not using a minicomputer from 1970, why should I be bound by the limits set then?
Yeah, I'm also one of these people silently enjoying systemd and wayland. Every now and then there's fuzz on one of these. I shrug, and move on still enjoying both of them.
Thanks! I hate this. 🖤
That's pretty clever.
$ 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
(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
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
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
Damn and does it work as an init too? xD.
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.