"the config file"... which ? Could you perhaps show that config file?
which command gives that output?

EDIT: ... and which system version do you have?

EDIT 2: ... as a start point: the error reported is a "local software error" rather than badness in the data. All Source indexes have a "Files" tag, so the question would be why the local software is buggy upon seeing that tag. Therefore it's important to know which system version you have and which version the software that shows this bug has.

The point of running certbot more often is simply because a renewal attempt may fail for many possible technical reasons. If you set it up to only run once a month, any such failure would lead to needing operator hands-on.

Therefore all such renewal processes have "busy wait" design that begins with the test if it's yet time for a renewal and return as failure if not. If it is time for renewal, an actual renewal attempt is made, and that may succeed or fail for external reasons. If it fails, then the next run will again discover that it (still) is time for renewal and make another attempt. Etc. When the renewal succeeds,  the local state changes so the next run will again opt out early because renewal is not (yet) needed.

Now, both that check for systemd and that randomized delay are unnecessary components. Your system does not need to check and re-check for the presence of systemd, since that is a constant.  And you can choose a random but fixed start time  for your certbot runs, which will be an equivalent collegial measure for avoiding clogging the remote end when actual renewal requests are made (there is no statistically motivated reason to pick a new random start time every time).

you're welcome.

@Altoid: spelling mistake is one thing; honouring us by treating us as equal is another

I'm  not sure where the security angle is, but it all sounds like it could be a fun project. Of course there are few other filesystem points that need to be writeable for a working system. Most if not all could probably be set up tempfs.

Wonderful. Let's wait together. When some packages turn up in Debian offering all or some of those good things you talk about, then they automatically turn up in Devuan. Unless they depend on systemd. If they do, they end up on the banned packages list. Unless someone takes on the effort of forking and untangling the systemd dependencies.

Talk is cheap.

There are numerous of ways to run programs, including to run programs that keeps other programs running. If a person wants their machine to do that then they would set it up to do so. Or are we working on a premise that end users are stupid, or that end users should be controlled (by owner-administrator-vendor)?

Looks to me like your system is all good and that you have run into a flaw in debian's package provisioning; namely that they happen to include a host that is currently unresponsive.

Debian packages are accessed (by your host) via the domain deb.debian.org which afaik is resolved by "fastly" into one (or possibly a few) actual host IP, and it happens that it transiently offers "bad" IP.

If you want your resolution of deb.debian.org go to a specific host of your choice, then you may set up that resolution in your /etc/hosts file.

Sometimes this kind of thing happens if your local meta files are outdated, in which case you will have to run apt-get update to freshen them.

Something funny is going on if the millisecond timestamp stays the same for the Xorg logs... are you sure that that is the current log file?

I  believe it would merely be a boot action aimed at restoring the brightness at boot up to a level that got captured at power down. So, a comfort utility. But I'm sure one can expand the concept to any level of complication and introduce all sorts of knick-knack with elaborate justifications and then you can add steak knives to that...

"before latest upgrade", "after latest upgrade" as well as "updates that came maybe a week ago" are all pretty lousy version identifiers.