restic: Backups segfault on ARMv7

I build restic with Jenkins from Github master as and when commits are pushed. Until this time I have not had any issues with it backing files up… until now 😭

Output of restic version

# restic version
debug log file debug.log
debug enabled
restic 0.9.6 (v0.9.6-135-ga307797c) compiled with go1.14 on linux/arm

How did you run restic exactly?

export B2_ACCOUNT_ID="XXXX"
export B2_ACCOUNT_KEY="XXXX"
export RESTIC_REPOSITORY="b2:restic-$(hostname | md5sum | awk '{print $1}')-$(hostname)"
export RESTIC_PASSWORD_FILE="/root/.restic"
export RESTIC_CACHE_DIR="/data/.restic"
restic init
restic backup /etc
restic backup /etc

The 1st backup of /etc will work ok, but the 2nd backup is when things segfault.

What backend/server/service did you use to store the repository?

Backblaze B2

Expected behavior

Restic should backup correctly. My last successful backup on this host was on the 27th Feb 2020. (I have another linux host that bacups hourly and is working just fine.)

Actual behavior

It dies with a Segmentation fault 😦

# restic backup /etc
debug log file debug.log
debug enabled
repository 4357d291 opened successfully, password is correct
Segmentation fault files 4.264 MiB, total 941 files 6.448 MiB, 0 errors ETA 0:47
root@ReadyNAS:~/test#
/etc/wgetrc

Each time I run a backup it crashes but It doesn’t stop at the same point in time or file.

Steps to reproduce the behavior

I’m just running a backup (well, attempting to)

Do you have any idea what may have caused this?

I am using a ReadyNAS Duo to run this backup on. It has 512MB of RAM, and lots of swap space allocated that it never actually uses.

Do you have an idea how to solve the issue?

Restic backs up just fine on a Linux x86_64 system with 16GB RAM. Maybe its a memory thing, but its odd that its only just stopped working. I have deleted my repo and started again with a fresh one at Backblaze so I don’t believe data to be corrupted.

Did restic help you today? Did it make you happy in any way?

Yes, and no.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 21 (11 by maintainers)

Commits related to this issue

Most upvoted comments

I think I found it. restic installs signal handlers with signal.Notify in various places, but uses unbuffered channels. When I make a few of the channels buffered, and I have overcommit set to 2, the SIGSEGV is properly caught by the Go runtime and I get

fatal error: runtime: out of memory

followed by a stack trace. Disabling overcommit shouldn’t even be necessary.