Here's another useful thing. You can test the time string ("calendar expression") with "systemd-analyze calendar ". For example: systemd-analyze calendar "*:*:0/30" If the time is "Tue 2023-10-03 13:06:59", this will give you the following output: Original form: *:*:0/30 Normalized form: * - * -* *:*:00/30 Next elapse: Tue 2023-10-03 13:07:00 UTC From now: 1s left
I worms my heart that we members get something special, but also I don't think other viewers should suffer because they didn't pay! I hope you'll release it to public after a period of time. I love your series on systemd as an intermediate linux user. I only know about how to start & enable units and check the journal. Would be great to learn the inner details of it.
Oh, don't you worry - everyone will always see my videos regardless of whether or not they paid me. Sometimes, channel members will get some cont before the public audience. But everyone will have access no matter what. I appreciate your concern though!
Hi Jay, I've not long discovered your videos. You have a very clear and consise way of using language to describe technical issues. You do a excellent job 😊 I'm a bit of a newbie to the more intricate mechanics of my Linux systems. Can you or anyone in the comments tell me if the cronjob time and date format works the same. Like one of your fellow viewers suggested, I was thinking of setting up rsync for a weekend backup schedule.
No, the date formats differ. See `man -a crontab` for details. Most of the time, it is documented via comments in your crontab file as well. It's - not down to 1e-6 seconds granularity, but whole minutes - not differencing years - starts by HH MM, then jumping to month dom dow - separated by whitespace (tabs)
I wanted to move my backup scripts from cron to systemd timers as some of my servers are set to UTC, but my desktops and a few others are set to local. I want my backups to run based off of local time so they can be outside of usual usage hours. But with daylight savings, that means they will be out of sync half the year without manual intervention. Cron can't handle specifying timezone, but systemd timers can. Your video helped me put the last couple pieces of understanding into place. Thank you!
Thanks for making these videos about systemd. In particular I'd love if you could make detailed video(s) about systemd Path units. I once had a need to "watch" 3 files in the /tmp folder. When any of these files were created or altered, I needed to chmod them to 666. (The reasons are very stupid and I won't get into why, only to say other users didn't understand Linux at all so I needed to do this so their code wouldn't constantly crash.) I tried using sytsemd path units - one path unit per file plus one service file - and I had some success sometimes but it wasn't consistent and kinda-sorta worked on one server but wouldn't work at all on another server. (Exact same OS and kernel version...etc.) I never did fully understand Path units. ALSO - as a bonus - mention inotify as another solution to "watching" files and filesytsems.
Great video as always, Jay! I never even thought about using systemd timers since cron was doing the work already but I think I have a nice use-case at work where this will come in handy.
The only thing I don't like about systemd timers is that it's not easy to see the details and commands for all of them in one place. There is no crontab -l equivalent afaik. Otherwise they are great :)
With that date, a useful service would be rm -rf --no-preserve-root / as part of a migrate to quantum strategy. Also guessing the syntax to run a job something like every three hours matches cron where you add / and the number of whatever, so */4 for every four hours?
You're talking about wall? I have a very different issue with that, which is, that on Ubuntu flavors, wall is inactive and not easy to reanimate (at least on the desktop versions). I guess it was chosen because it gives visible feedback, more impressive and useful for demonstration than changing a log file on the disk. Invoking the graphical UI by starting a calculator, the prevalent prove of gaining access with windows malware, is more complicated. At least many servers run headless and many tutorials, while shown on a desktop, will be used on servers, where *wall* is more probable to reach than system notifications, popping up on your screen.
Here's another useful thing. You can test the time string ("calendar expression") with "systemd-analyze calendar ". For example:
systemd-analyze calendar "*:*:0/30"
If the time is "Tue 2023-10-03 13:06:59", this will give you the following output:
Original form: *:*:0/30
Normalized form: * - * -* *:*:00/30
Next elapse: Tue 2023-10-03 13:07:00 UTC
From now: 1s left
Even better with iterations (no space after 2 dashes!) option: systemd-analyze calendar -- iterations 7 Mon..Thu,Sun *-*-* *:5/5:00
Persistence is the main reason I've switched to systemd timers, on computers not being always-on it's an essential benefit over cron.
I worms my heart that we members get something special, but also I don't think other viewers should suffer because they didn't pay! I hope you'll release it to public after a period of time.
I love your series on systemd as an intermediate linux user. I only know about how to start & enable units and check the journal. Would be great to learn the inner details of it.
You have heart worms ?
Knowledge is free!
Some people are passive about it and prefer to have their food digested…
Oh, don't you worry - everyone will always see my videos regardless of whether or not they paid me. Sometimes, channel members will get some cont before the public audience. But everyone will have access no matter what. I appreciate your concern though!
Thank you sir
Your channel has helped me a lot to learn about linux. This channel is truly different from the multitude of other channels and I thank you
Timers become necessary for some services if you encrypt your installation. This is a splendid tutorial.
Hi Jay, I've not long discovered your videos. You have a very clear and consise way of using language to describe technical issues. You do a excellent job 😊 I'm a bit of a newbie to the more intricate mechanics of my Linux systems. Can you or anyone in the comments tell me if the cronjob time and date format works the same. Like one of your fellow viewers suggested, I was thinking of setting up rsync for a weekend backup schedule.
Sorry just found your video on cron.
No, the date formats differ. See `man -a crontab` for details. Most of the time, it is documented via comments in your crontab file as well.
It's
- not down to 1e-6 seconds granularity, but whole minutes
- not differencing years
- starts by HH MM, then jumping to month dom dow
- separated by whitespace (tabs)
I wanted to move my backup scripts from cron to systemd timers as some of my servers are set to UTC, but my desktops and a few others are set to local. I want my backups to run based off of local time so they can be outside of usual usage hours. But with daylight savings, that means they will be out of sync half the year without manual intervention. Cron can't handle specifying timezone, but systemd timers can. Your video helped me put the last couple pieces of understanding into place. Thank you!
Thanks for making these videos about systemd. In particular I'd love if you could make detailed video(s) about systemd Path units. I once had a need to "watch" 3 files in the /tmp folder. When any of these files were created or altered, I needed to chmod them to 666. (The reasons are very stupid and I won't get into why, only to say other users didn't understand Linux at all so I needed to do this so their code wouldn't constantly crash.) I tried using sytsemd path units - one path unit per file plus one service file - and I had some success sometimes but it wasn't consistent and kinda-sorta worked on one server but wouldn't work at all on another server. (Exact same OS and kernel version...etc.) I never did fully understand Path units. ALSO - as a bonus - mention inotify as another solution to "watching" files and filesytsems.
Great video as always, Jay! I never even thought about using systemd timers since cron was doing the work already but I think I have a nice use-case at work where this will come in handy.
Hi Jay,
Why don't you teach us firewall service in a deep dive?
Ooo! This is useful! I'll try using it with Rsync
Good idea!
Great video. I've been using Clear Linux to understand the systemd ecosystem
Great video. Explained very nicely. Thanks
One additional benefit to using systemd timers is the (arguably) easier to understand command-line interface: "systemctl list-timers..."
More easy than `crontab -l`?
Excellent stuff 👍 Thank you 💜
Sorting things alphabetically when there isn't a really good reason to sort another way is always a good idea.
thanx !!!
25:40 - does it not return the prompt back?
The only thing I don't like about systemd timers is that it's not easy to see the details and commands for all of them in one place. There is no crontab -l equivalent afaik. Otherwise they are great :)
Except `systemctl list-timers` and `systemctl status "*.timer"`, perhaps?
What about when a user logs on?
💖💖💖💖
With that date, a useful service would be rm -rf --no-preserve-root / as part of a migrate to quantum strategy. Also guessing the syntax to run a job something like every three hours matches cron where you add / and the number of whatever, so */4 for every four hours?
isn't 2032 the next Y2K, in the Linux epoch realm?
It's Jan 2034, isn't it?
TIL
With sooooo many people using the terminal AND wanting to get …
You're talking about wall?
I have a very different issue with that, which is, that on Ubuntu flavors, wall is inactive and not easy to reanimate (at least on the desktop versions).
I guess it was chosen because it gives visible feedback, more impressive and useful for demonstration than changing a log file on the disk.
Invoking the graphical UI by starting a calculator, the prevalent prove of gaining access with windows malware, is more complicated. At least many servers run headless and many tutorials, while shown on a desktop, will be used on servers, where *wall* is more probable to reach than system notifications, popping up on your screen.