> Any time you have disasters or large crimes, you can connect them to children and children's things.
This time you have an actual connection, the state of the world notwithstanding. If you factor in the world however, with this many wars, I'd say it's pretty much linked, regardless of the way you assembled words to make it look like it doesn't, and doubling down doesn't make it less distant from reality.
Not by itself if it's naive, but if it's able to assess target health and avoid degraded instances then it becomes a component in HA, the other being integrating an orchestrator for gracious recovery.
> PgDog does not detect primary failure and will not call pg_promote(). It is expected that the databases are managed externally by another tool, like Patroni or AWS RDS, which handle replica promotion.
I had this problem with https://gitlab.com/gabriel.chamon/yagi which is Yet Another Stalker Gamma Installer. In my region, Brazil, I get cloudflare captchas when downloading assets from moddb. Using a VPN solves this but then latency and speed goes out the window. What worked for this particular case was to use an unmodified Firefox build and interact with it indirectly with it's limited interface: launch the browser with the download URL, solve captcha once, have the automation look for the download start at the browser's sqlite db then wait for the download to finish looking at the filesystem. Anything, even marionette would trigger cloudflares anti automation, even if I was solving the captcha manually.
> The medical establishment and journalism have found it extremely uncomfortable over the past decade to notice that obesity has negative health consequences because it might embarrass some fat people
Maybe, or maybe it's the bottomless pockets of the sugar industry lobby.
> Have diets really gotten noticeably unhealthier over recent decades?
Diet is only one of the factors on obesity and it's health consequences, you also have stress, sleep deprivation, lack of exercises, loneliness and isolation.
Diet and exercise (to lesser extent) are the mechanism of obesity. The other factors may affect diet and exercise. A massive other factor for the latter is driving.
I wonder what robust protection would mean in practice for such a capable tool like an agent...
Looking at the trifecta axis, if we assume we can't control untrusted content, that leaves us to create safeguards for private data access and external communication.
Would it be enough if we had a buffer between when these two happened: access to the environment and access to the web?
Gitlab.com used to be slightly less available than GitHub but recently I think the tables have turned and Gitlab saas is relatively stable.
I also enjoy Gitlab as a platform. It's got everything, good board, good repo, good issues, good CI, extremely good registries. It's got the equivalent of gists and pages... It a better product all things considered.
GitHub just wins because of popularity. It's WordPress all over again, the thing people use because it's a thing people use.
Wouldn't it be faster to swap to vram if you are sitting there with 8gigs of it unused than swapping to ssd and burning its write cycles, assuming you absolutely need swap
Moved from cronie to systemd timers because they are resilient to system startup times. My backup strategy is to create a borg archive entry every day at a fixed time. With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available.
Cronie has a mechanism for this, called "anacron", which is called hourly by cron (on my system, /etc/cron.hourly/0anacron), and performs all the /etc/cron.{daily,weekly,monthly} tasks, no matter if the earliest possible schedule was missed (and with a configurable random delay). You can modify /etc/anacrontab to create custom schedules.
To do this at the user level, you can add something like "@hourly anacron -t /path/to/anacrontab -S /path/to/spooldir" to the user's crontab, though I've never tried this.
Many cron implementations have a similar mechanism.
This isn't the same as with systemd timer because timer lets you specify when you want to run your service exactly and will fallback to running when the system comes online. With @hourly I lose this control and multiple machines could potentially trigger backups at the same time, hogging the physical hard drives and the network.
> fallback to running when the system comes online.
That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.
I prefer the deterministic behavior of cron, the script will run when it is specified to run, as you said earlier, as long as the system is running; and as I stated in a separate comment, it will run @reboot if I need it to run then.
> With @hourly I lose this control and multiple machines could potentially trigger backups at the same time
Then don't use @hourly, use staggered times, it's very easy.
> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.
There are two options to fix it;
Disable persist so no catching up on missing scripts. Set OnBoot=5m so it gets ran 5 minutes after boot, so your script (say backup) is ran on boot first, then every time on schedule
Enable persist but just add sleep in ExecStartPre - very "cron" way but there is just no in-systemd option to enable "catch up" script to be delayed
Sadly no option to "run catch-up timers with delay" at least yet
> Then don't use @hourly, use staggered times, it's very easy.
Not in cron. In systemd it's just RandomizedOffsetSec=30m and it is "stable" - same host with same job will always have same delay so on multiple hosts it is spread nicely. There is also non-stable version
> That isn't something I'd want to happen, it sounds like it creates a potential queue of scripts that will flood the system on start, if it works the way you described.
This isn't what happens. If you leave it offline for days it'll only trigger the service only a single time.
I interpreted it more like "I have these 500 different cronjobs all spread out across $unit_of_time. If the system is down for longer than $unit_of_time and then comes back, does all 500 jobs start running instantly (since they missed their previous deadline)?"
Just to be clear, this isn't default systemd timer behaviour, you need to opt in by setting Persistent=true. If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool because at that scale you'd surely need better observability
You could implement this with a gitlab instance in a separate system, like two VMs in proxmox or two physical machines, and a shell executor running in them. Gitlab CI has a nice feature to limit concurrency by using resource groups. Say you have 500 jobs spread through the day and the system stays offline for a while, when it comes online it'll start processing the jobs, but will only run a single one at a time. You get visibility, logs, queue monitoring and an API to query data.
> If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool
Eh sometimes, but you can get pretty far with one of two approaches:
1. Careful use of Requires= and Wants= to group your scripts into chains of jobs, which achieves fixed parallel (though at 100s of jobs, I hope you're generating those unit files with a tool like Puppet or https://github.com/karlicoss/dron or something and not doing this by hand).
2. Even better, just use a lockfile. `ExecStart="flock -F $TMPDIR/mylock <command>"` is pretty hard to beat. Use -F so as not to confuse KillMode and resource accounting and you're golden. Just don't use flock(1) timeouts; let systemd handle that. Heck, if you have that many cron jobs, you should be doing this even if you don't use systemd; otherwise job latency changes can cause reboot-style thundering herds out of the blue.
1. This is spread across 500 files, maintainability goes out the window
2. If this for some reason fails, misconfiguration or unexpected shutdown, you could have a failure that's hard to track or debug
These are fine with a few services chained together, but this requires a shallow depth of dendencies. To have these theoretical hundreds of jobs chained together like this isn't practical or safe.
If you have 100 different jobs that were supposed to run over the past week, but didn't because offline, when you restart, they they all flood the system on start.
100 jobs all running at different times throughout the week is a very different load than them all falling back and running at the same time on system boot.
No, just different cron schedules. If I just reboot a machine the job doesn't get triggered, only if I start a machine after the cron schedule should have been triggered. To be fair, if I start two machines in these conditions this will happen too, but such situation is much more manageable than rebooting too machines in a short period of time.
> With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available.
This time you have an actual connection, the state of the world notwithstanding. If you factor in the world however, with this many wars, I'd say it's pretty much linked, regardless of the way you assembled words to make it look like it doesn't, and doubling down doesn't make it less distant from reality.
reply