non-zero exit status -11

[abclution]

Command '('attic', 'create', '/BACKUPS/motherbrain.office.group.com-attic-repo::pm1-2016-01-16T10:59:44.511694', '/', '/volumes/mypool-8tb/SCRIPTS', '/volumes/mypool-8tb/Q-Drive', '/volumes/mypool-8tb/H-Drive', '', '/volumes/mypool-8tb/P-Drive', '/volumes/mypool-8tb/Dropbox', '--exclude-from', '/etc/atticmatic/excludes', '--verbose', '--stats')' returned non-zero exit status -11

Soooo, what does this mean? This happens every time at a specific point in the backup in the same folder..

[ThomasWaldmann]

not sure, but iirc attic only uses 0 (ok) and 1 (error).

so maybe this is caused by an external signal?

-11 sounds a bit like signal 11, but the docs say, that should be rather exit code 128+11 = 139 (or -117 if interpreted as signed int8). Following that logic, -11 == 245 == 128+117 == signal 117 (which is not known to mean anything special, afaik).

[enkore]

-11 is SIGSEGV, which Attic/Borg can't catch in Python-space: some C code crashed.

[ThomasWaldmann]

@enkore is it really? do you know why that does not follow the 128+11 rule?

[enkore]

I think the 128+SIGNAL rule is something the shell does, not the called process ... this doesn't look like the output comes from a shell. E.g. if you have a process that does a SIGSEGV and you run it with something like Python subprocess you'll see -11, not 139.

[blueness]

let's get a trace and see where it dies.

[ThomasWaldmann]

tw@tux:~$ sleep 1000  # now i used kill -SIGSEGV PID-of-sleep in another window
Speicherzugriffsfehler (Speicherabzug geschrieben)
tw@tux:~$ echo $?
139

and

>>> subprocess.call(["sleep", "1000"])  # now i used kill -SIGSEGV PID-of-sleep in another window
-11

[ThomasWaldmann]

@abclution so, you invoke attic from python / from a python tool? or some other wrapper that is not a shell?

if so, I guess you can close this. SIGSEGV is a serious error, often caused by hardware malfunctioning, attic can't do much against this.