kernel: ... (conftest) ... exited on signal 11

pchris

Well-Known Member
Code:
root@stern:~ # grep conftest /var/log/messages
Jan  2 02:33:17 stern kernel: pid 87949 (conftest), jid 601, uid 0: exited on signal 11 (core dumped)
Jan  2 03:42:42 stern kernel: pid 22577 (conftest), jid 619, uid 0: exited on signal 11 (core dumped)
Jan  4 08:03:29 stern kernel: pid 85636 (conftest), jid 677, uid 0: exited on signal 11 (core dumped)
Jan  4 10:43:18 stern kernel: pid 74732 (conftest), jid 697, uid 0: exited on signal 11 (core dumped)
Jan  7 19:22:45 stern kernel: pid 40333 (conftest), jid 785, uid 0: exited on signal 11 (core dumped)
Jan  7 20:36:28 stern kernel: pid 84503 (conftest), jid 803, uid 0: exited on signal 11 (core dumped)
Jan  8 02:12:47 stern kernel: pid 8278 (conftest), jid 815, uid 0: exited on signal 11 (core dumped)
Jan  8 02:18:38 stern kernel: pid 13244 (conftest), jid 823, uid 0: exited on signal 11 (core dumped)

Was passiert hier? Wie kann ich Abhilfe schaffen?
 

mr44er

moderater Moderator
Teammitglied
Mehr swap, aber zuerst mal gucken, was da genau so fix Speicher zieht.

Nutzt du ZFS? Wenn ja, begrenze mal den ARC.
Hast du VMs?
 

pchris

Well-Known Member
Folgende Angaben kann ich dazu machen.

Code:
root@stern:~ # grep memory /var/run/dmesg.boot
real memory  = 12884901888 (12288 MB)
avail memory = 12243238912 (11676 MB)

Code:
root@stern:~ # swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/gpt/swap0    2097152    57888  2039264     3%
/dev/gpt/swap1    2097152    58564  2038588     3%
Total             4194304   116452  4077852     3%

ARC ist bereits begrenzt.
Code:
root@stern:~ # sysctl vfs.zfs.arc_max
vfs.zfs.arc_max: 6442450944

VMs laufen keine. Allerdings startet jede Nacht poudriere.
 

mr44er

moderater Moderator
Teammitglied
Also swap ist ausreichend vorhanden (weil das doppelte als gewöhnlich) und nicht stark ausgelastet. Zumindest jetzt bei der Stichprobe ohne poudriere.

Ich würde zunächst mal im BIOS den shared RAM/vRAM bei der gpu auf den kleinsten Wert begrenzen, wenn nicht schon geschehen.

In der loader.conf würde ich vfs.zfs.arc_max="2G" oder sogar erstmal nur vfs.zfs.arc_max="1G" setzen, das Verhalten beobachten und dann kann man immer noch wieder schrittweise hochdrehen.

Oder eben den RAM auf maximal ausbauen , je nachdem ob du die Investition tätigen willst, ob das Board das kann oder ob es das noch wert ist etc.

Ich vermute, dass poudriere beim Bauen mal mehr oder weniger stark mit dem ARC kollidiert. firefox und rust sind z.B. sehr fett anspruchsvoll geworden, was man so hört.
 

stadtkind

Well-Known Member
Code:
root@stern:~ # grep conftest /var/log/messages
Jan  2 02:33:17 stern kernel: pid 87949 (conftest), jid 601, uid 0: exited on signal 11 (core dumped)
Jan  2 03:42:42 stern kernel: pid 22577 (conftest), jid 619, uid 0: exited on signal 11 (core dumped)
Jan  4 08:03:29 stern kernel: pid 85636 (conftest), jid 677, uid 0: exited on signal 11 (core dumped)
Jan  4 10:43:18 stern kernel: pid 74732 (conftest), jid 697, uid 0: exited on signal 11 (core dumped)
Jan  7 19:22:45 stern kernel: pid 40333 (conftest), jid 785, uid 0: exited on signal 11 (core dumped)
Jan  7 20:36:28 stern kernel: pid 84503 (conftest), jid 803, uid 0: exited on signal 11 (core dumped)
Jan  8 02:12:47 stern kernel: pid 8278 (conftest), jid 815, uid 0: exited on signal 11 (core dumped)
Jan  8 02:18:38 stern kernel: pid 13244 (conftest), jid 823, uid 0: exited on signal 11 (core dumped)

Was passiert hier? Wie kann ich Abhilfe schaffen?

Hast du ein paar Ports mit Poudriere gebaut? Das Skript configure von den Autotools testet welche Funktionen/Libs das System so hat und dabei wird das kompilierte conftest (fuer jeden Test wird ein neues conftest erzeugt) halt manchmal mit einem SIGSEV gekillt (http://src.illumos.org/source/xref/freebsd-head/sys/sys/signal.h#93).


Passiert oefter, siehe z.B. https://muc.lists.freebsd.current.narkive.com/0QmgRu98/signal-11-for-conftest-poudriere-jails
 

pchris

Well-Known Member
Danke für die Antwort. Dann passiert das wohl tatsächlich während des poudriere Laufs. Es ist also unkritisch und kann ignoriert werden.
 

pchris

Well-Known Member
Ergänzung: Ich habe während eines poudriere-Laufs mir minütlich die laufenden Prozesse gesichert.

/var/log/messages:
Code:
Jan 13 18:20:43 stern kernel: pid 90276 (conftest), jid 27, uid 0: exited on signal 11 (core dumped)

So sah es im Speicher aus:
Code:
last pid: 86717;  load averages:  2.70,  2.49,  2.34  up 1+05:50:17    18:20:00
52 processes:  5 running, 47 sleeping
CPU: 31.5% user,  0.4% nice,  4.0% system,  0.0% interrupt, 64.0% idle
Mem: 1360M Active, 1665M Inact, 594M Laundry, 6720M Wired, 1381M Free
ARC: 2387M Total, 1493M MFU, 761M MRU, 4568K Anon, 41M Header, 89M Other
     1962M Compressed, 2412M Uncompressed, 1.23:1 Ratio
Swap: 4096M Total, 799M Used, 3297M Free, 19% Inuse

Am Laufen waren:
pkg-static create mit dem samba413 Paket und
allerlei Prozesse vom gcc9 Build (gmake, cc1plus).

Bestätigt also nochmals die Antwort von stadtkind.
 
Oben