I’ve set a systemd timer to run a Restic backup script daily, but each time it’s supposed to run it ends with an error. I checked the status log of the service and it’s the following:
Feb 28 08:35:07 fedora systemd[1871]: Starting restic-backup.service - Restic backup service...
Feb 28 08:35:07 fedora restic[1895]: open repository
Feb 28 08:35:07 fedora restic[1895]: Fatal: unable to open config file: Stat: Get "https://s3.us-west-004.backblazeb2.com/REDACTED/?location=": dial tcp: lookup s3.us-west-004.bac>
Feb 28 08:35:07 fedora restic[1895]: Is there a repository at the following location?
Feb 28 08:35:07 fedora restic[1895]: s3:s3.us-west-004.backblazeb2.com/REDACTED
Feb 28 08:35:07 fedora systemd[1871]: restic-backup.service: Main process exited, code=exited, status=1/FAILURE
Feb 28 08:35:07 fedora systemd[1871]: restic-backup.service: Failed with result 'exit-code'.
Feb 28 08:35:07 fedora systemd[1871]: Failed to start restic-backup.service - Restic backup service.
The config files are present though and I’ve confirmed the script works multiple times, by running it manually with systemctl --user start restic-backup. This only happens with the daily timer. Any idea of what’s going on?
Hmm this looks OK. But could you expand the line with unable to open config file? There is something going on with connection/name resolution maybe? (dial tcp: lookup…)
From the initial error message: Get "https://s3.us-west-004.backblazeb2.com/REDACTED/?location=": dial tcp: lookup s3.us-west-004.bac>
Please check that you are able to connect to that server, for example, using curl https://s3.us-west-004.backblazeb2.com (should return an AccessDenied error).
Do you have any proxy settings or similar configured?
systemctl cat <service> will also tell you the applied unit configuration systemd is using, including any drop-ins that may have been forgotten about; looking at the .service file doesn’t always tell the whole story.
I’ve seen connect/DNS failures in systemd services when using certain sandboxing directives.
Feb 29 08:55:47 fedora restic[1837]: Fatal: unable to open config file: Stat: Get "https://s3.us-west-004.backblazeb2.com/REDACTED/?location=": dial tcp: lookup s3.us-west-004.backblazeb2.com: Temporary failure in name resolution
I can connect into it though, curl returns the AccessDenied error. No proxies or anything that I’m using.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Error>
<Code>AccessDenied</Code>
<Message>Unauthenticated requests are not allowed for this api</Message>
</Error>
This is what it looks like when I do systemctl --user cat restic-backup
# /home/duck/.config/systemd/user/restic-backup.service
[Unit]
Description=Restic backup service
[Service]
Type=oneshot
ExecStart=restic backup --verbose --one-file-system --tag systemd.timer --exclude-file /home/duck/.config/Restic/exclude.txt --exclude-if-present .exclude_from_backup --files-from /home/duck/.config/Restic/include.txt
ExecStartPost=restic forget --verbose --tag systemd.timer --group-by "paths,tags" --keep-daily $RETENTION_DAYS --keep-weekly $RETENTION_WEEKS --keep-monthly $RETENTION_MONTHS --keep-yearly $RETENTION_YEARS
EnvironmentFile=%h/.config/Restic/restic-backup.conf
# /usr/lib/systemd/user/service.d/10-timeout-abort.conf
# This file is part of the systemd package.
# See https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer.
#
# To facilitate debugging when a service fails to stop cleanly,
# TimeoutStopFailureMode=abort is set to "crash" services that fail to stop in
# the time allotted. This will cause the service to be terminated with SIGABRT
# and a coredump to be generated.
#
# To undo this configuration change, create a mask file:
# sudo mkdir -p /etc/systemd/user/service.d
# sudo ln -sv /dev/null /etc/systemd/user/service.d/10-timeout-abort.conf
[Service]
TimeoutStopFailureMode=abort
Additionally you can also try to run the following command on a shell as the user of the service:
This tries a name resolution for the given FQDN:
❯ systemd-run --user --wait -p SuccessExitStatus=11 dig +short s3.us-west-004.backblazeb2.com
Running as unit: run-u1637.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 196ms
CPU time consumed: 15ms
You can check the output of the command like this afterwards:
