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.
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.
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.
me: systemd is not that bloated
systemd:
Try scheduling a cron tab job to run a task on dates defined that way.
But that’s not what I need and the world revolves around me…
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
Not that that’s bad when it’s stuff like this
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
I feel like the glued together collection of scripts was way worse to manage than systemd.
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
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.
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.
Systemd’s method is more powerful than Cron syntax.
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.
Can you tell Cron to catch up on the things that should’ve happened but didn’t because the system was off?
I think fcron and anacron can do that
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
Micro anyone? :D
ed is the standard text editor.
Emacs, but I only use 'M-x butterfly C-M-c`
the only reason im not using it is that it makes copying from terminal impossible
It will copy to the clipboard if possible. You can probably get it working with a bit of tinkering: https://github.com/zyedidia/micro/blob/master/runtime/help/copypaste.md
Enough people mention it that I’ve jumped over to helix
alias systemd-texted=micro
Have you tried emacs with evil mode? It’s a bit slow, not as slow as VS code or anything, but not really fast. But it’s basically neovim but you get to use lisp to configure it instead of lua
Thanks! I hate this. 🖤
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?
I wouldn’t cry about it if it wasn’t so God awful to work with
I’ve felt like systemd has been a breeze compared to the hodgepodge of different stuff that preceded it. Now most distros have it mostly the same way, tools are well documented, things works together. It wasn’t always like that from what I remember
In what way?
That’s pretty clever.
Finally we can put all the controversy around systemd to rest.
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
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.
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)
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
What do you mean? You literally just change the
/etc/sshd
config 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
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
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
It is, but they searched starting in 2025. Skipping this one.
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.
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.
$ 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
Damn and does it work as an init too? xD.