Jan Alexander Steffens (heftig) authored 3 years ago and Kristian Klausen committed 3 years ago

- When loki hits 5.5G RSS, aggressively reclaim its memory. This puts
  it under memory pressure.
- When loki hits 6G RSS, invoke the kernel OOM killer.
- When loki is under severe memory pressure, have systemd-oomd kill it.

Jan Alexander Steffens (heftig) authored 3 years ago and Kristian Klausen committed 3 years ago

- Allow killing of any cgroup if swap is about to run out. When swap is
  at least 90% full, oomd will kill a cgroup, tending to kill the cgroup
  with the highest swap usage.
- Allow killing cgroups of logged in users under severe memory pressure.
  When a cgroup is stalled waiting for memory at least 60% of the time,
  for at least 30 seconds, oomd will attempt to kill it or one of its
  descendant cgroups.

This partially reverts commit c3d00264.

The smartd changes are not ready to land yet and were included in the
above commit by accident.

phrik has a polkit rule for demize to restart phrik

Some people love to do 48 req/s to our tracker which causes ~100% cpu.
For now we allow 5req/sec with a burst of 10 requests.

Ref: service-agreements!16

- Drop the custom service file, use the packaged one
- Merge in the comments from the packaged config file

After=network-online.target is likely insufficient by itself.

Fixes: 104d08a1 ("archweb: Put most services after network-online.target")
Fixes: c844d0cb ("Split storage box monitoring into new text collector")

We noticed readlinks and reporead on gemini failing to connect to the
archweb database immediately after rebooting. To fix this, place them
after network-online.target. Do the same for all but one of the other
service units even though they run on timers 10-15 minutes after boot
for completeness and correctness.

The JournalHandler doesn't support flushing, anyway.

Fix #177

Fix #371

It has been applied upstream[1] and released with smartmontools 7.2[2].

[1] https://github.com/smartmontools/smartmontools/commit/61bc85ecadf9e5596b140380fed701a674e38a1b
[2] https://github.com/smartmontools/smartmontools/releases/tag/RELEASE_7_2

This reverts commit b4c97002.

Ref: archlinux/service-agreements!16

We used to set query_cache_type to 0 in the default settings but we were
also setting query_cache_size to a non-zero/non-default value, which was
in turn re-enabling the query cache. Update the configuration to reflect
the actual cache state and make sure query_cache_size is set to zero for
the "query_cache_type = 0" case.

Now that the setting controls the real state of the query cache, disable
it for bbs.archlinux.org; its hit rate is small compared to insert rate.

Default query_cache_type to 0 and innodb_file_per_table to true.

Main motivation behind this is preparing for doing more automatic
upgrades. The need for ignoring kernel updates isn't clear either.

Hetzner DNS has been delaying many responses for 5 seconds, causing
outgoing federation work to pile up, almost running into OOM before we
noticed.

I don't know if were being throttled because federation makes a *lot* of
requests. Anyway, using Cloudflare DNS seems to solve it.

Enable DNSOverTLS for this because we can.