Threads for cuu508
-
chilton
6 months ago
|
link
| on:
Schedule Cronjob for the First Monday of Every Month, the Funky Way
Too magic for me. You can add a date/time/day screen on the shell script behind a cron job in less than ten lines of shell. I’m not happy that you have to look both at the script and the crontab to figure it out but I’m happier with that. Best would probably be something like:
0 0 1-7 * * : 'My First Monday only cronjob' && [ $(date '+%a') -eq 'Mon' ] && run-mycronjob.shAssuming I have the fields right.
-
-
-
Absolutely true. Also still arguably better than the original solution. The original solution is probably native to the cron package that the author uses. It’s not guaranteed to work anywhere else. Further, like a lot of tools in Unix, cron is terse as a result of its heritage from systems that would today be considered puny. Put a different way, me in 1985 would be astounded at how much computing power I can buy in 2022 in the form of a Raspberry Pi Zero. You should not embrace that terseness. The Systemd/Timer solutions are much better than the cron solutions presented. And I would say that if you are on a box without systemd, you’d still be better off to implement the “only on the first Monday of the month check” in shell rather than through clever manipulation of the cron parameters.
-
In retrospect, I should have emphasized in the post that the described trick is primarily a trick, a hack, an interesting curiosity.
PS. It’s really hard to buy a Raspberry Pi Zero in 2022, unfortunately. I wanted one for a hobby hardware project, I ended up getting a Radxa Zero. But point stands, the price/performance/size of computers in 2022 is awesome.
-
-
-
-
-
mperham
edited
6 months ago
|
link
| on:
Schedule Cronjob for the First Monday of Every Month, the Funky Way
I feel like this is treading very close to implementation-specific behavior. Other cron systems, written in other programming languages, may not implement this exact behavior.
-
-
I am a happy user of https://healthchecks.io at the free tier.
-
Seconded. I use healthchecks.io for my automated backups. When the backup completes, it simply makes a curl request to a certain endpoint. healthchecks.io “knows” approximately what time that request should be arriving, and if it doesn’t arrive within a specified window around that time (say, an hour) then it sends me an email that something failed. It’s been working beautifully with zero maintenance for years
-
You can also track how long a command takes. My backup script looks like this:
curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/$ID/start nice /usr/bin/tarsnap $ARGS curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/$ID/$?(where $ID is my healthcheck identifier and $ARGS are my tarsnap arguments, and $? is the status from the command). Now if the job doesn’t complete within the grace time, I get an alert, and I can see how long the jobs took on the status page.
-
-
-
-
-
A related question: what do you do with the cables you don’t need? I too have a few boxes full of cables. I don’t think I’ll need 10 spare mini USB cable, 10 spare micro USB cables, and so on. But it feels wrong to just throw them away.
-
This. I may have dozens of different USB-A to micro-USB cables laying around. Different materials, different lengths, some only for power delivery… I don’t throw them just in case I need an specific length/color some day, but… I also tend to gift cables to everyone that asks for one while visiting lol
-
-
-
Does this mean all other UNIX-based OSes (or at least Vixie-cron using distros) don’t do this properly (e.g., running the same job twice when time jumps backwards)? That would be pretty messed up.
-
The Debian patch says it’s originally from OpenBSD, so OpenBSD is likely similar. I haven’t experimented with other OSes yet.
-
-
the upstream repo looks more nostalgic than really active: https://github.com/vixie/cron
It looks to me that a community fork to upstream all these things to is better than having all these patches maintained in various distributions.
-
-
-
-
Interesting read. I still think servers should only ever use UTC as their timezone
-
UTC is not monotonically continuously increasing either. Leap seconds can skip your execution moment as well as repeat it.
-
-
I’m picturing something where the wakeup time is close enough to 1 minute that you could miss a minute. It seems like it will do the right thing if it’s less than a 5 second leap, because they wait up to 65 seconds: https://salsa.debian.org/debian/cron/-/blob/master/debian/patches/features/Better-timeskip-handling.patch#L497
I think the other time logic would save it in the unprecedented case of 5 leap seconds.
My point was wrong because I was imagining some sort of sleep that could set you close enough to a minute that even UTC doesn’t help. I didn’t read the code before to see if this happened in the non-patched case. If that were the case, you could possibly want constantly increasing continuous time like GPS time: http://leapsecond.com/java/gpsclock.htm
-
-
That’s probably 12 9s of correctness. As backblaze says, there’s more likelihood of an asteroid hitting the earth…
-
-
-
-
-
-
-
It would be nice to have a standard API or html element or something to make selection uniform across all sites. We could integrate it into the browser settings.
-
-
I wasn’t aware iptables could be used to simulate packet loss like this. I would have turned to tc disc or whatever the command is.
-
iptables is only useful for very simplistic loss simulation.
The iptables statistic module has support for random and dropping every nth packet, but real-world packet loss is usually correlated and bursty. tc shines when you need a loss model that more accurately matches what you’d see in the wild (also when you need to simulate delays, duplicate packets, reordered packets, etc.)
-
For sure, it would be unusual to see 80% packet loss in the real world. More likely, it would flip-flop between 100% and 0%. I was just testing where the limit is. A bursty packet loss would be an interesting followup experiment.
Now thinking about the bursty scenario: leaving out the “–retry-delay” and doing the exponential back-off might allow more requests to eventually succeed. But the use case is the blog article is “heartbeat messages to a monitoring service”. Each request tells the server “Checking in – I’m still alive!”. For this use case, if the client experiences severe packet loss, maybe it shouldn’t report itself as healthy. In other words, trying to get the request through at any cost isn’t always the correct thing to do.
-
-
-
I can totally relate with the “too low energy to work on meaningful stuff” part:
I’d spend a long day working at my day job and doing a lot of software development there. Then I wouldn’t have the energy to make real progress on my app, so I’d tell myself that upgrading one of the packages that was out-of-date was a good use of my time.
I think the solution is finding and arranging dedicated time for the sideproject. For example, go from full-time to part-time, and make the side-project your other, equally important “day job”.
-
Hello, author of Healthchecks.io here! This is interesting, looks like in certain cases (you are running Prometheus & friends already, and are familiar with setting up the alerting rules) it’s a good option. I’m all for using the building blocks you already have!
One thing I’m curious about is in what situations people would choose to self-host. My current understanding (a guess, really), is that:
- homelabbers self-host stuff for the fun of it, and for the learning experience. It’s the whole point of having a homelab
- large companies might need to self-host because of regulatory requirements and policies (“all data must be under our direct control”, “all data must stay in country X”, “we needed a custom, semi-proprietary feature so we are running a patched fork” etc.)
But for smaller teams and companies with no special requirements, what would motivate self-hosting? Quite a bit of engineering time goes into setting up and maintaining a production-grade service. With SaaS, this cost would be amortized across many customers. I’m thinking $16/mo should be a non-consequential expense for a company. Even a couple hours of saved engineer’s time per month should be more valuable than that. Am I wrong in thinking that?
-
Can only speak for myself, but a 3rd scenario might be bootstrapped startups (which might be over-represented in forums like this). I agree that $16/mo is non-consequential for a ‘normal’ company. But I try to keep recurring costs down as much as possible, as those add up, and every few-hundred bucks I can save count. So I accept that I won’t have as reliable as possible monitoring, but since I’m only starting out, and working on this full-time (which means I usually spot issues fairly quickly anyway, and the consequences are not as bad as they would be otherwise), and I have other (self-hosted) infrastructure anyway around my product, it’s an acceptable trade-off.
Should I ever achieve a reliable income stream, I’d most likely go for a hosted service instead. Maybe not for all of my self-hosted stuff. But monitoring would be one of the first things I’d outsource I think.
-
Would it be feasible to add DNS-over-TLS service directly to pihole?
(haven’t used pihole, but have toyed with the idea, specifically to block ads in Android)
-
The more often you deploy code the more comfortable you get with your tools and your process. It’s better if you are in a position to push code changes at any time, and have confidence that the process won’t leave your app in a half-broken state.
Another thing that takes some pressure off is a good unit test coverage. Passing tests don’t guarantee everything will work perfectly, of course, but at least I can have some level of confidence that there are no big obvious blunders in the code I’m shipping.
-
jgrahamc (Cloudflare’s CTO) 4 hours ago:
It looks like they got help which is nice. But I think this is just a grace period until they will have to figure out something again. I’m not so sure if a project like this can rely on companies like CF to absorb the costs forever.