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.
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.)
Yeah and they actually added some usability in the form of that utility helping you debug what you’re doing. Pretty nice!
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
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
What do you mean? You literally just change the
/etc/sshdconfig to point at a different port do you not?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
I run systemd with a different sshd service port and that’s all I changed
.Aube it’s distro dependent, but Ubuntu updated ssh a while ago to be passed through systemd. Updating the port requires systemd configuration changes
Okay this is cool and all, but why would systemd have a calendar?
(also how do i do this)
As others have said on this thread, it’s because systemd has fairly advanced timer system that basically requires implementing a calendar.
To do it, the command is in the screenshot
systemd-analyze calendar "Tue *-12-25".
Thanks! I hate this. 🖤
That’s pretty clever.
How is Tuesday Christmas optimal?
I suppose for people in the office, it means everyone else has fucked off and the week is basically a wash.
Students here usually get Mondays off when the next Tuesday is a holiday. As a university sysadmin, I cherish those days because that’s when we can get actual work done without having to work around the chaotic classroom reservations or work in ten-minute bursts during breaks. It’s also when we can implement changes to the network and update the servers because the office workers don’t tend to come in.
The last time that happened, all of us sysadmins did about three months’ worth of actual work in a few hours, then used the smaller lecture hall as a cinema for the rest of the day.
I guess that makes a long weekend with Christmas Eve and then Christmas?
Is Friday Christmas just as good?
Not in Germany, where 25th and 26th are bank holidays. So having these close to the prior or following weekend makes for four days off
Seems like it would be, maybe OP has more reasons to think why Tuesday is more optimal.
That’s actually really cool!
Too bad about its failure as an init system, though.
You must be either the very old get off my lawn type or very young and edgy. Everyone else in between likes systemd, one of the best things that happened to GNU/Linux in a while.
This just like Emacs all over again!
No, emacs is superior
No, nobody forces you to use emacs at gunpoint.
Some emacs evangelicals would like to.
Whoever forced you? distros wanting a stable system?
removed by mod
Both systemd and pulseaudio were more or less directly architected after MacOS’ design of Core Audio and launchd.
Really shows how little you actually know.
I’ve worked with both coreaudio and launchd.
They weren’t architected like trash, and actually did their jobs well.
If systemd was just like launchd that would be awesome, it’s not, then it took over half the linux userspace, badly.
removed by mod
Open source dev, kernel, llvm, jvm, bunch of other shit.
Never came up with anything as bad as systemd.
Don’t talk shit if you don’t know, been doing software since the internet was dialup.
What, Emacs is a successful init system https://github.com/a-schaefers/systemE
If by failure you mean every system under the sun using it
I don’t think they are using popularity as a metric. But I think the functionality of it is also very good, so dunno what their gripe is.
$ 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 OKNo Christmas for 5 years?? Why are you doing this to us, systemd???
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.
Use a systemd timer to send yourself a reminder. Discoverd them recently myself and honestly liking them more than cron.
Using a large shell history (currently at 57283 entries) along with readline (and sometimes fzf) has served me well over the past few yeas when trying to remember past commands.
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 keep a persistent “sticky note” (in KDE) drop down on my top bar where I copy/paste important commands, scripts, etc.
I actually remember to use it sometimes.
I make a separate text file per command so I can search them!
Which I dont.
We can store those text files in a terminal and search for them from the command line with man command!
I usually print these out and put them in a safe deposit box at a bank so I never lose them
I feel you. It’s however gotten a lot better since I turned some of these commands into abbreviations. They’re aliases that expands in place, more or less. Fish has them natively, I personally use zsh-abbr.
Fish is super useful, but I usually only start it up if I’m having trouble finding or remembering a command.
Yeah, it’s a good shell. I’ve found the lack of compatibility with some bash tools to be inconvenient enough that I just went back to zsh and found alternatives for the parts that I liked about it. Works well enough for me.
I’m relatively new to Linux in general (have only been on it for about a year and a half, but have taken to it like a fish to water), so forgive me if this is a dumb question, but what are some benefits to using zsh over bash? Are there any cons?
Honestly, it’s just another shell. Both Bash and ZSH happen to be mostly POSIX compliant, so stuff that works for Bash tends to work with ZSH too. For me it’s mostly just about the stuff I can add to it - I use the antidote plugin manager to get additional autocomplete, syntax highlighting, suggestions, async prompt updates, that kind of thing.
Damn and does it work as an init too? xD.
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
Just write your own initialization system in bash. It is more reliable and less bloated.
God, I only have one question…
Why?
I bet it’s for timers
Did you know the next Friday the 13th is in December? ChatGPT didn’t know it. (I had to give it an extra date.now for it to figure it out)
