Výpadky GitLabu 01/2022 #67

Open
opened 2022-01-29 18:43:11 +01:00 by Disassembler · 9 comments
Disassembler commented 2022-01-29 18:43:11 +01:00 (Migrated from git.spotter.cz)

@Podhorecky: Nejsem z toho moudrý (a neočekávám ani, že vy budete), takže tu jen víceméně sesumarizuji co vím s nějakými svými poznámkami a anotacemi.

tl;dr je, že ten systém operuje na hranici svých možností a pomohlo by mu se nějakého workloadu zbavit. Největšími žrouty paměti jsou (v tomto pořadí): GitLab, ClamAV (antivirus používaný mailovým systémem, ale na ten možná budu schopen něco vymyslet), Decidim, Odoo.


Analýza

GitLab chcípne s chybou 502, protože se zakousnou některé jeho procesy. Dochází k tomu někde v jádru systému a když se to stane, produkuje to ve /var/log/kern.log a v sériové konzoli logy podobné následujícím

Výpisy z logů
Jan 28 05:44:27 server kernel: [44106.684312] BUG: kernel NULL pointer dereference, address: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.688988] #PF: supervisor instruction fetch in kernel mode
Jan 28 05:44:27 server kernel: [44106.689278] #PF: error_code(0x0010) - not-present page
Jan 28 05:44:27 server kernel: [44106.689548] PGD 0 P4D 0 
Jan 28 05:44:27 server kernel: [44106.689748] Oops: 0010 [#2] SMP PTI
Jan 28 05:44:27 server kernel: [44106.689972] CPU: 1 PID: 10506 Comm: bundle Tainted: G      D           5.13.0-27-generic #29~20.04.1-Ubuntu
Jan 28 05:44:27 server kernel: [44106.690420] Hardware name: Hetzner vServer, BIOS 20171111 11/11/2017
Jan 28 05:44:27 server kernel: [44106.690721] RIP: 0010:0x0
Jan 28 05:44:27 server kernel: [44106.690950] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
Jan 28 05:44:27 server kernel: [44106.691260] RSP: 0000:ffffab7302ae7bb8 EFLAGS: 00010282
Jan 28 05:44:27 server kernel: [44106.691529] RAX: 0000000000000000 RBX: ffffab7302ae7cf0 RCX: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.691847] RDX: 0000000000000000 RSI: fffff4c485056680 RDI: ffff9f0924b43400
Jan 28 05:44:27 server kernel: [44106.692181] RBP: ffffab7302ae7c20 R08: 000000000000001c R09: 00000000000009d8
Jan 28 05:44:27 server kernel: [44106.692506] R10: ffffab7302ae7b88 R11: 0000000000000003 R12: fffff4c485056680
Jan 28 05:44:27 server kernel: [44106.692827] R13: ffffab7302ae7c58 R14: 0000000000000000 R15: ffffffff8aa411c0
Jan 28 05:44:27 server kernel: [44106.693148] FS:  00007fd6504bdf80(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000
Jan 28 05:44:27 server kernel: [44106.693558] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 28 05:44:27 server kernel: [44106.693838] CR2: ffffffffffffffd6 CR3: 000000021fa48001 CR4: 00000000007706e0
Jan 28 05:44:27 server kernel: [44106.694154] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.694476] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 28 05:44:27 server kernel: [44106.694798] PKRU: 55555554
Jan 28 05:44:27 server kernel: [44106.694992] Call Trace:
Jan 28 05:44:27 server kernel: [44106.695213]  read_pages+0x1fb/0x280
Jan 28 05:44:27 server kernel: [44106.695487]  ? add_to_page_cache_lru+0x78/0xd0
Jan 28 05:44:27 server kernel: [44106.695745]  page_cache_ra_unbounded+0x146/0x1f0
Jan 28 05:44:27 server kernel: [44106.696057]  do_page_cache_ra+0x3d/0x40
Jan 28 05:44:27 server kernel: [44106.696286]  filemap_fault+0x4f4/0x9b0
Jan 28 05:44:27 server kernel: [44106.696506]  ? do_set_pte+0xc8/0x140
Jan 28 05:44:27 server kernel: [44106.696736]  ext4_filemap_fault+0x32/0x50
Jan 28 05:44:27 server kernel: [44106.696970]  __do_fault+0x3e/0xc0
Jan 28 05:44:27 server kernel: [44106.697180]  do_fault+0x1ea/0x440
Jan 28 05:44:27 server kernel: [44106.697399]  __handle_mm_fault+0x619/0x8e0
Jan 28 05:44:27 server kernel: [44106.697642]  handle_mm_fault+0xda/0x2b0
Jan 28 05:44:27 server kernel: [44106.697868]  do_user_addr_fault+0x1bb/0x650
Jan 28 05:44:27 server kernel: [44106.698109]  exc_page_fault+0x7d/0x170
Jan 28 05:44:27 server kernel: [44106.698347]  ? asm_exc_page_fault+0x8/0x30
Jan 28 05:44:27 server kernel: [44106.698583]  asm_exc_page_fault+0x1e/0x30
Jan 28 05:44:27 server kernel: [44106.698810] RIP: 0033:0x7fd65055a68c
Jan 28 05:44:27 server kernel: [44106.699041] Code: d1 48 8d 14 c8 31 c9 eb 21 0f 1f 44 00 00 81 fe 50 e5 74 64 0f 84 74 01 00 00 83 fe 02 48 0f 44 c8 48 83 c0 38 48 39 c2 74 3c <8b> 30 83 fe 01 75 dd 48 8b 70 10 4c 8b 0b 4c 01 c6 49 39 f1 72 e1
Jan 28 05:44:27 server kernel: [44106.699812] RSP: 002b:00007fd64fa70b70 EFLAGS: 00010246
Jan 28 05:44:27 server kernel: [44106.700085] RAX: 00007fd64f80b040 RBX: 00007fd64fa70cb0 RCX: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.700400] RDX: 00007fd64f80b2a8 RSI: 0000000000000000 RDI: 0000000000000040
Jan 28 05:44:27 server kernel: [44106.700715] RBP: 0000000000000079 R08: 00007fd64f80b000 R09: 00007fd640d5e140
Jan 28 05:44:27 server kernel: [44106.701033] R10: 0000000000000000 R11: 0000000000000000 R12: 00007fd6505622d0
Jan 28 05:44:27 server kernel: [44106.701351] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
Jan 28 05:44:27 server kernel: [44106.701678] Modules linked in: xt_multiport xt_nat xt_addrtype xt_mark xt_comment ipt_REJECT nf_reject_ipv4 xt_set ip_set_hash_ip veth xt_MASQUERADE xt_state xt_conntrack xt_tcpudp ip_set_hash_net ip_set nfnetlink ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter overlay input_leds joydev serio_raw bridge stp llc sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel xhci_pci crypto_simd psmouse cryptd xhci_pci_renesas virtio_net net_failover virtio_scsi failover floppy
Jan 28 05:44:27 server kernel: [44106.704724] CR2: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.704954] ---[ end trace 18bf93f57f5e5c7e ]---
Jan 28 05:44:27 server kernel: [44106.705198] RIP: 0010:0x0
Jan 28 05:44:27 server kernel: [44106.705396] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
Jan 28 05:44:27 server kernel: [44106.705715] RSP: 0000:ffffab7301c57bb8 EFLAGS: 00010286
Jan 28 05:44:27 server kernel: [44106.705984] RAX: 0000000000000000 RBX: ffffab7301c57cf0 RCX: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.706303] RDX: 0000000000000000 RSI: fffff4c486dfaa00 RDI: ffff9f0ac87b5a00
Jan 28 05:44:27 server kernel: [44106.706617] RBP: ffffab7301c57c20 R08: 0000000000000098 R09: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.706943] R10: ffffab7301c57b88 R11: 0000000000003327 R12: fffff4c486dfaa00
Jan 28 05:44:27 server kernel: [44106.707281] R13: ffffab7301c57c58 R14: 0000000000000000 R15: ffffffff8aa411c0
Jan 28 05:44:27 server kernel: [44106.707609] FS:  00007fd6504bdf80(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000
Jan 28 05:44:27 server kernel: [44106.708053] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 28 05:44:27 server kernel: [44106.708335] CR2: ffffffffffffffd6 CR3: 000000021fa48001 CR4: 00000000007706e0
Jan 28 05:44:27 server kernel: [44106.708657] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 28 05:44:27 server kernel: [44106.709061] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 28 05:44:27 server kernel: [44106.709503] PKRU: 55555554
Jan 28 11:00:26 server kernel: [63065.536851] general protection fault, probably for non-canonical address 0x3f3fd247e88d44f4: 0000 [#3] SMP PTI
Jan 28 11:00:26 server kernel: [63065.537694] CPU: 1 PID: 409741 Comm: thread_pool.rb* Tainted: G      D           5.13.0-27-generic #29~20.04.1-Ubuntu
Jan 28 11:00:26 server kernel: [63065.538385] Hardware name: Hetzner vServer, BIOS 20171111 11/11/2017
Jan 28 11:00:26 server kernel: [63065.538785] RIP: 0010:rwsem_down_write_slowpath+0x5ad/0x5f0
Jan 28 11:00:26 server kernel: [63065.539097] Code: a8 02 75 a9 49 8d 57 08 48 89 c1 48 83 c9 02 f0 48 0f b1 0a 74 97 a8 01 74 93 a8 02 74 ea eb 8d f0 49 83 0f 02 e9 3a fb ff ff <8b> 42 34 85 c0 0f 84 b1 fa ff ff 8b 7a 48 48 31 c0 0f 1f 40 00 84
Jan 28 11:00:26 server kernel: [63065.539886] RSP: 0018:ffffab73015f7ae0 EFLAGS: 00010246
Jan 28 11:00:26 server kernel: [63065.540184] RAX: 3f3fd247e88d44c0 RBX: ffff9f09b63a19c0 RCX: ffff9f09b63a19c0
Jan 28 11:00:26 server kernel: [63065.540501] RDX: 3f3fd247e88d44c0 RSI: 0000000000000002 RDI: 0000000000000000
Jan 28 11:00:26 server kernel: [63065.540864] RBP: ffffab73015f7b90 R08: 00007fd63db86000 R09: ffffffff89aaf400
Jan 28 11:00:26 server kernel: [63065.541182] R10: ffff9f0a11747540 R11: 0000000000000001 R12: ffff9f0a02815598
Jan 28 11:00:26 server kernel: [63065.541531] R13: ffff9f0ad3019700 R14: ffff9f0a02815598 R15: ffff9f0a02815598
Jan 28 11:00:26 server kernel: [63065.541877] FS:  0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000
Jan 28 11:00:26 server kernel: [63065.542303] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 28 11:00:26 server kernel: [63065.542579] CR2: 00007f80b798c000 CR3: 000000010d5f2005 CR4: 00000000007706e0
Jan 28 11:00:26 server kernel: [63065.542935] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 28 11:00:26 server kernel: [63065.543264] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 28 11:00:26 server kernel: [63065.543588] PKRU: 55555554
Jan 28 11:00:26 server kernel: [63065.543787] Call Trace:
Jan 28 11:00:26 server kernel: [63065.543992]  ? __mod_memcg_state+0x2f/0x40
Jan 28 11:00:26 server kernel: [63065.544302]  ? unlink_anon_vmas+0x153/0x1c0
Jan 28 11:00:26 server kernel: [63065.544638]  down_write+0x41/0x50
Jan 28 11:00:26 server kernel: [63065.544955]  unlink_file_vma+0x33/0x60
Jan 28 11:00:26 server kernel: [63065.545273]  free_pgtables+0x9b/0xf0
Jan 28 11:00:26 server kernel: [63065.545574]  exit_mmap+0xbe/0x1f0
Jan 28 11:00:26 server kernel: [63065.545877]  mmput+0x5d/0x130
Jan 28 11:00:26 server kernel: [63065.546165]  do_exit+0x324/0xaf0
Jan 28 11:00:26 server kernel: [63065.546478]  ? hrtimer_init_sleeper+0x80/0x80
Jan 28 11:00:26 server kernel: [63065.546818]  do_group_exit+0x43/0xb0
Jan 28 11:00:26 server kernel: [63065.547117]  get_signal+0x171/0x880
Jan 28 11:00:26 server kernel: [63065.547442]  arch_do_signal_or_restart+0xf2/0x290
Jan 28 11:00:26 server kernel: [63065.547807]  ? _copy_from_user+0x2b/0x60
Jan 28 11:00:26 server kernel: [63065.548174]  exit_to_user_mode_prepare+0x12f/0x1c0
Jan 28 11:00:26 server kernel: [63065.548569]  syscall_exit_to_user_mode+0x27/0x50
Jan 28 11:00:26 server kernel: [63065.548975]  do_syscall_64+0x6e/0xb0
Jan 28 11:00:26 server kernel: [63065.549341]  ? do_syscall_64+0x6e/0xb0
Jan 28 11:00:26 server kernel: [63065.549705]  ? syscall_exit_to_user_mode+0x27/0x50
Jan 28 11:00:26 server kernel: [63065.550108]  ? do_syscall_64+0x6e/0xb0
Jan 28 11:00:26 server kernel: [63065.550480]  ? sysvec_apic_timer_interrupt+0x4e/0x90
Jan 28 11:00:26 server kernel: [63065.550876]  ? asm_sysvec_apic_timer_interrupt+0xa/0x20
Jan 28 11:00:26 server kernel: [63065.551303]  entry_SYSCALL_64_after_hwframe+0x44/0xae
Jan 28 11:00:26 server kernel: [63065.551715] RIP: 0033:0x7fd6505357b1
Jan 28 11:00:26 server kernel: [63065.564753] Code: Unable to access opcode bytes at RIP 0x7fd650535787.
Jan 28 11:00:26 server kernel: [63065.565194] RSP: 002b:00007fd6182fce20 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
Jan 28 11:00:26 server kernel: [63065.565757] RAX: fffffffffffffdfc RBX: 00007fd64245bd3c RCX: 00007fd6505357b1
Jan 28 11:00:26 server kernel: [63065.566196] RDX: 0000000000000000 RSI: 0000000000000089 RDI: 00007fd64245bd54
Jan 28 11:00:26 server kernel: [63065.566646] RBP: 00007fd64245bd28 R08: 0000000000000000 R09: 00000000ffffffff
Jan 28 11:00:26 server kernel: [63065.567094] R10: 00007fd6182fcf20 R11: 0000000000000246 R12: 00007fd64245bd4c
Jan 28 11:00:26 server kernel: [63065.567417] R13: 00007fd650025010 R14: 00007fd64245bd54 R15: 00007fd6182fce70
Jan 28 11:00:26 server kernel: [63065.567764] Modules linked in: xt_multiport xt_nat xt_addrtype xt_mark xt_comment ipt_REJECT nf_reject_ipv4 xt_set ip_set_hash_ip veth xt_MASQUERADE xt_state xt_conntrack xt_tcpudp ip_set_hash_net ip_set nfnetlink ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter overlay input_leds joydev serio_raw bridge stp llc sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel xhci_pci crypto_simd psmouse cryptd xhci_pci_renesas virtio_net net_failover virtio_scsi failover floppy
Jan 28 11:00:26 server kernel: [63065.571499] ---[ end trace 18bf93f57f5e5c7f ]---
Jan 28 11:00:26 server kernel: [63065.571833] RIP: 0010:0x0
Jan 28 11:00:26 server kernel: [63065.572055] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
Jan 28 11:00:26 server kernel: [63065.572454] RSP: 0000:ffffab7301c57bb8 EFLAGS: 00010286
Jan 28 11:00:26 server kernel: [63065.572767] RAX: 0000000000000000 RBX: ffffab7301c57cf0 RCX: 0000000000000000
Jan 28 11:00:26 server kernel: [63065.573220] RDX: 0000000000000000 RSI: fffff4c486dfaa00 RDI: ffff9f0ac87b5a00
Jan 28 11:00:26 server kernel: [63065.573541] RBP: ffffab7301c57c20 R08: 0000000000000098 R09: 0000000000000000
Jan 28 11:00:26 server kernel: [63065.573869] R10: ffffab7301c57b88 R11: 0000000000003327 R12: fffff4c486dfaa00
Jan 28 11:00:26 server kernel: [63065.574233] R13: ffffab7301c57c58 R14: 0000000000000000 R15: ffffffff8aa411c0
Jan 28 11:00:26 server kernel: [63065.574631] FS:  0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000
Jan 28 11:00:26 server kernel: [63065.575235] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 28 11:00:26 server kernel: [63065.575646] CR2: ffffffffffffffd6 CR3: 000000010d5f2005 CR4: 00000000007706e0
Jan 28 11:00:26 server kernel: [63065.576099] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 28 11:00:26 server kernel: [63065.576547] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 28 11:00:26 server kernel: [63065.576991] PKRU: 55555554
Jan 28 11:00:26 server kernel: [63065.577245] Fixing recursive fault but reboot is needed!
Jan 28 11:01:32 server kernel: [63131.986855] general protection fault, probably for non-canonical address 0x3f3fd247e88d44f4: 0000 [#4] SMP PTI
Jan 28 11:01:32 server kernel: [63131.993305] CPU: 1 PID: 412842 Comm: scheduler.rb:73 Tainted: G      D           5.13.0-27-generic #29~20.04.1-Ubuntu
Jan 28 11:01:32 server kernel: [63131.993804] Hardware name: Hetzner vServer, BIOS 20171111 11/11/2017
Jan 28 11:01:32 server kernel: [63131.994110] RIP: 0010:rwsem_down_write_slowpath+0x5ad/0x5f0
Jan 28 11:01:32 server kernel: [63131.994424] Code: a8 02 75 a9 49 8d 57 08 48 89 c1 48 83 c9 02 f0 48 0f b1 0a 74 97 a8 01 74 93 a8 02 74 ea eb 8d f0 49 83 0f 02 e9 3a fb ff ff <8b> 42 34 85 c0 0f 84 b1 fa ff ff 8b 7a 48 48 31 c0 0f 1f 40 00 84
Jan 28 11:01:32 server kernel: [63131.995189] RSP: 0018:ffffab730207fab0 EFLAGS: 00010246
Jan 28 11:01:32 server kernel: [63131.995464] RAX: 3f3fd247e88d44c0 RBX: ffff9f09a8afedd0 RCX: ffff9f09a8afedd0
Jan 28 11:01:32 server kernel: [63131.995784] RDX: 3f3fd247e88d44c0 RSI: 0000000000000002 RDI: 0000000000000000
Jan 28 11:01:32 server kernel: [63131.996175] RBP: ffffab730207fb60 R08: 00007fd63db86000 R09: ffffffff89aaf400
Jan 28 11:01:32 server kernel: [63131.996603] R10: ffff9f0a0d5bc340 R11: 0000000000000001 R12: ffff9f0a02815598
Jan 28 11:01:32 server kernel: [63131.996971] R13: ffff9f0ad3019700 R14: ffff9f0a02815598 R15: ffff9f0a02815598
Jan 28 11:01:32 server kernel: [63131.997367] FS:  0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000
Jan 28 11:01:32 server kernel: [63131.997909] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 28 11:01:32 server kernel: [63131.998295] CR2: 00007fd63e25dfc0 CR3: 0000000109124004 CR4: 00000000007706e0
Jan 28 11:01:32 server kernel: [63131.998735] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 28 11:01:32 server kernel: [63131.999178] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 28 11:01:32 server kernel: [63131.999616] PKRU: 55555554
Jan 28 11:01:32 server kernel: [63131.999893] Call Trace:
Jan 28 11:01:32 server kernel: [63132.000183]  ? __mod_memcg_state+0x2f/0x40
Jan 28 11:01:32 server kernel: [63132.000508]  ? unlink_anon_vmas+0x153/0x1c0
Jan 28 11:01:32 server kernel: [63132.000802]  down_write+0x41/0x50
Jan 28 11:01:32 server kernel: [63132.001089]  unlink_file_vma+0x33/0x60
Jan 28 11:01:32 server kernel: [63132.001378]  free_pgtables+0x9b/0xf0
Jan 28 11:01:32 server kernel: [63132.001705]  exit_mmap+0xbe/0x1f0
Jan 28 11:01:32 server kernel: [63132.002018]  mmput+0x5d/0x130
Jan 28 11:01:32 server kernel: [63132.002288]  do_exit+0x324/0xaf0
Jan 28 11:01:32 server kernel: [63132.002573]  do_group_exit+0x43/0xb0
Jan 28 11:01:32 server kernel: [63132.002871]  get_signal+0x171/0x880
Jan 28 11:01:32 server kernel: [63132.003190]  arch_do_signal_or_restart+0xf2/0x290
Jan 28 11:01:32 server kernel: [63132.003516]  exit_to_user_mode_prepare+0x12f/0x1c0
Jan 28 11:01:32 server kernel: [63132.003807]  syscall_exit_to_user_mode+0x27/0x50
Jan 28 11:01:32 server kernel: [63132.004153]  do_syscall_64+0x6e/0xb0
Jan 28 11:01:32 server kernel: [63132.004413]  ? syscall_exit_to_user_mode+0x27/0x50
Jan 28 11:01:32 server kernel: [63132.004741]  ? do_syscall_64+0x6e/0xb0
Jan 28 11:01:32 server kernel: [63132.004999]  ? syscall_exit_to_user_mode+0x27/0x50
Jan 28 11:01:32 server kernel: [63132.005261]  ? do_syscall_64+0x6e/0xb0
Jan 28 11:01:32 server kernel: [63132.005487]  ? do_syscall_64+0x6e/0xb0
Jan 28 11:01:32 server kernel: [63132.005717]  ? do_syscall_64+0x6e/0xb0
Jan 28 11:01:32 server kernel: [63132.005944]  ? asm_exc_page_fault+0x8/0x30
Jan 28 11:01:32 server kernel: [63132.006202]  entry_SYSCALL_64_after_hwframe+0x44/0xae
Jan 28 11:01:32 server kernel: [63132.006471] RIP: 0033:0x7fd650535376
Jan 28 11:01:32 server kernel: [63132.006700] Code: Unable to access opcode bytes at RIP 0x7fd65053534c.
Jan 28 11:01:32 server kernel: [63132.007003] RSP: 002b:00007fd6174f93f0 EFLAGS: 00000282 ORIG_RAX: 00000000000000ca
Jan 28 11:01:32 server kernel: [63132.007417] RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 00007fd650535376
Jan 28 11:01:32 server kernel: [63132.007747] RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fd6193d9094
Jan 28 11:01:32 server kernel: [63132.008080] RBP: 00007fd6193d9068 R08: 0000000000000000 R09: 0000000000000004
Jan 28 11:01:32 server kernel: [63132.008420] R10: 0000000000000000 R11: 0000000000000282 R12: 00007fd6193d908c
Jan 28 11:01:32 server kernel: [63132.008735] R13: 00007fd650025010 R14: 00007fd6174f9430 R15: 00007fd6193d9094
Jan 28 11:01:32 server kernel: [63132.009056] Modules linked in: xt_multiport xt_nat xt_addrtype xt_mark xt_comment ipt_REJECT nf_reject_ipv4 xt_set ip_set_hash_ip veth xt_MASQUERADE xt_state xt_conntrack xt_tcpudp ip_set_hash_net ip_set nfnetlink ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter overlay input_leds joydev serio_raw bridge stp llc sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel xhci_pci crypto_simd psmouse cryptd xhci_pci_renesas virtio_net net_failover virtio_scsi failover floppy
Jan 28 11:01:32 server kernel: [63132.012499] ---[ end trace 18bf93f57f5e5c80 ]---
Jan 28 11:01:32 server kernel: [63132.012753] RIP: 0010:0x0
Jan 28 11:01:32 server kernel: [63132.012960] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
Jan 28 11:01:32 server kernel: [63132.013340] RSP: 0000:ffffab7301c57bb8 EFLAGS: 00010286
Jan 28 11:01:32 server kernel: [63132.013722] RAX: 0000000000000000 RBX: ffffab7301c57cf0 RCX: 0000000000000000
Jan 28 11:01:32 server kernel: [63132.014151] RDX: 0000000000000000 RSI: fffff4c486dfaa00 RDI: ffff9f0ac87b5a00
Jan 28 11:01:32 server kernel: [63132.014596] RBP: ffffab7301c57c20 R08: 0000000000000098 R09: 0000000000000000
Jan 28 11:01:32 server kernel: [63132.015066] R10: ffffab7301c57b88 R11: 0000000000003327 R12: fffff4c486dfaa00
Jan 28 11:01:32 server kernel: [63132.015504] R13: ffffab7301c57c58 R14: 0000000000000000 R15: ffffffff8aa411c0
Jan 28 11:01:32 server kernel: [63132.015851] FS:  0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000
Jan 28 11:01:32 server kernel: [63132.016267] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 28 11:01:32 server kernel: [63132.016547] CR2: ffffffffffffffd6 CR3: 0000000109124004 CR4: 00000000007706e0
Jan 28 11:01:32 server kernel: [63132.016913] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 28 11:01:32 server kernel: [63132.017247] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 28 11:01:32 server kernel: [63132.017588] PKRU: 55555554
Jan 28 11:01:32 server kernel: [63132.017848] Fixing recursive fault but reboot is needed!

Ve výpisu jsou zmíněny procesy, resp. vlákna bundle, thread_pool.rb a scheduler.rb. Všechny by měly být spouštěny webovým serverem Puma, který je psaný v Ruby (proto ta vlákna s *.rb na konci), který GitLab používá. Ve výpisu stromu procesů jsou vidět zombie procesy bundle, nicméně ta zombifikace bude nejspíše symptom, nikoliv příčina.

Dále jsou ve výpisu procesů také vidět různé procesy čekající na diskové I/O, které s výše uvedenými nemusí vždy souviset. Zdá se, že jde o procesy, které prováděly diskové operace ve chvíli kdy ke kernel bugu došlo. Při minulém incidentu mezi nimi byl například i postgres nebo procesy Onlyoffice běžící v odděleném kontejneru. Teď vidím ssh daemona GitLabu. Při obou incidentech byl ve výpisu zachycen i proces pro vytváření záloh WordPressu, rep. jejich kompresi (nutno podotknout, že tar v tomto případě data z disku pouze čte a předává je rourou gzip procesu, který je komprimuje a zapisuje zpět na disk. Viset ale zůstal tar. Vzhledem k neobvyklosti problému to ale nemusí nic znamenat).

A taktéž je ve výpisu vidět podproces jádra pro zkompaktnění paměťových stránek (článek s popisem), který čeká na I/O.

Výpisy stromů procesů
   2271 ?        Ssl    0:51 /usr/libexec/podman/conmon --api-version 1 -c c2e6acfa470734e8fb950fef2acc928761c6d862c04b4f0e07eb0d6ac4fbebd4 -u c2e6acfa470734e
   2276 ?        Ss     0:00  \_ /bin/bash /assets/wrapper
   2983 ?        S      0:05      \_ runsvdir -P /opt/gitlab/service log: ......
   4115 ?        Ss     0:00      |   \_ runsv puma
   4117 ?        Ssl    2:04      |   |   \_ puma 5.5.2 (unix:///var/opt/gitlab/gitlab-rails/sockets/gitlab.socket,tcp://127.0.0.1:8080) [gitlab-puma-worker]
 409734 ?        Zl     0:01      |   |   |   \_ [bundle] <defunct>
 412712 ?        Zl     0:00      |   |   |   \_ [bundle] <defunct>
   2271 ?        Ssl    0:51 /usr/libexec/podman/conmon --api-version 1 -c c2e6acfa470734e8fb950fef2acc928761c6d862c04b4f0e07eb0d6ac4fbebd4 -u c2e6acfa470734e
   2276 ?        Ss     0:00  \_ /bin/bash /assets/wrapper
  88153 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 0 of 100-200 startups
  94373 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 1 of 100-200 startups
  98593 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 2 of 100-200 startups
  98935 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 3 of 100-200 startups
  99031 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 4 of 100-200 startups
  99276 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 5 of 100-200 startups
  99561 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 6 of 100-200 startups
  99676 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 7 of 100-200 startups
  99722 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 8 of 100-200 startups
  99739 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 9 of 100-200 startups
  99777 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 10 of 100-200 startups
 103683 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 11 of 100-200 startups
 106965 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 12 of 100-200 startups
 107038 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 13 of 100-200 startups
 107294 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 14 of 100-200 startups
 107364 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 15 of 100-200 startups
 107431 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 16 of 100-200 startups
 108648 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 17 of 100-200 startups
 108718 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 18 of 100-200 startups
 108989 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 19 of 100-200 startups
 111469 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 20 of 100-200 startups
 111673 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 21 of 100-200 startups
 111792 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 22 of 100-200 startups
 113582 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 23 of 100-200 startups
 114846 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 24 of 100-200 startups
 114978 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 25 of 100-200 startups
 114980 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 26 of 100-200 startups
 115831 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 27 of 100-200 startups
 116243 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 28 of 100-200 startups
 117174 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 29 of 100-200 startups
 122585 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 30 of 100-200 startups
 127300 ?        D      0:00      \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 31 of 100-200 startups
    461 ?        Ss     0:02 /usr/sbin/cron -f
 703772 ?        S      0:00  \_ /usr/sbin/CRON -f
 703775 ?        Ss     0:00      \_ /bin/sh -c /root/backup.sh >/dev/null
 703779 ?        S      0:00          \_ /bin/sh /root/backup.sh
 703896 ?        D      0:06              \_ tar cf - wordpress
 703897 ?        S      1:01              \_ gzip -9
     30 ?        D      1:17  \_ [kcompactd0]

Poslední jmenovaný je vzhledem k vytížení systému hlavním podezřelým. Systém většinu času operuje na hranici svých možností, co se zaplnění RAM a swapu týče, a kernel bugy naznačují, že k problému dochází právě při pokusu o přístup či uvolnění paměti.


Pokusy o zmírnění dopadu

1) Ve stávající situaci byl SSH port GitLabu otevřen pro přístup do celého světa, během čehož byl bombardován pokusy o přístup s neplatnými údaji, které byly odmítány a při opakování promptně zaříznuty fail2banem. Omezil jsem přístup pouze na rozsahy IP adres používané ISP v Česku. Kdyby se někdy outsourcovaly nějaké věci kolem kódu v GitLabu do Indie nebo na jiné Slovensko, bude potřeba ta omezení upravit.

Nečekám že by tato akce měla jakýkoliv dopad na vytížení, protože SSH daemon je oproti některým ostatním službám běžícím na server naprosto titěrný, ale není důvod to neudělat. Obzvlášť když byl SSH daemon při jednom z incidentů postižen.

2) ClamAV po startu drží celou databázi antivirových vzorků v paměti, aby s nimi mohl bleskurychle pracovat a nepotřeboval dodatečné přístupy na disk. Databáze obsahuje cca 8,7 milionu vzorků a rozbalená a zaindexovaná zabírá cca 1 GB v paměti RAM. Vzhledem k tomu, že používáme i virové databáze třetích stran, včetně takových které reagují na nové hrozby dynamicky, je pro maximální možnou ochranu potřeba jejich databáze obnovovat v řádu minut. Při obnovení databáze dochází k jejímu nahrání do paměti zatímco předchozí verze v paměti stále existuje a pracuje se s ní. Každých 5 minut (interval obnovy) tedy využití RAM ClamAV špičkově vyskočí na dvojnásobek a drží se tam po dobu cca 30 sekund, dokud se obnovená nová databáze nenačte a stará kopie nezahodí, čímž dojde k uvolnění paměti.

Nastavil jsem tedy v tuto chvíli ConcurrentDatabaseReload no v /etc/clamav/clamd.conf, což způsobí, že ClamAV nebude uchovávat kopii databáze v paměti během obnovy, ale místo toho nejprve starou databázi zahodí a pak teprve načte novou. To by mělo poměrně značně snížit fluktuace využité paměti, za cenu toho, že doručení některých mailů může být zdrženo v řádu jednotek minut.

Trvalé řešení, které nejprve musím navrhnout a otestovat, je mít dvě souběžné instance ClamAV. Jednu s hlavní databází, která se obnovuje pouze jednou za den, a druhou instanci s tou "online" databází, která je podstatně menší a může se tak obnovovat častěji a rychleji než v současnosti.

@Podhorecky: Nejsem z toho moudrý (a neočekávám ani, že vy budete), takže tu jen víceméně sesumarizuji co vím s nějakými svými poznámkami a anotacemi. tl;dr je, že ten systém operuje na hranici svých možností a pomohlo by mu se nějakého workloadu zbavit. Největšími žrouty paměti jsou (v tomto pořadí): GitLab, ClamAV (antivirus používaný mailovým systémem, ale na ten možná budu schopen něco vymyslet), Decidim, Odoo. --- **Analýza** GitLab chcípne s chybou 502, protože se zakousnou některé jeho procesy. Dochází k tomu někde v jádru systému a když se to stane, produkuje to ve `/var/log/kern.log` a v sériové konzoli logy podobné následujícím <details><summary>Výpisy z logů</summary> ``` Jan 28 05:44:27 server kernel: [44106.684312] BUG: kernel NULL pointer dereference, address: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.688988] #PF: supervisor instruction fetch in kernel mode Jan 28 05:44:27 server kernel: [44106.689278] #PF: error_code(0x0010) - not-present page Jan 28 05:44:27 server kernel: [44106.689548] PGD 0 P4D 0 Jan 28 05:44:27 server kernel: [44106.689748] Oops: 0010 [#2] SMP PTI Jan 28 05:44:27 server kernel: [44106.689972] CPU: 1 PID: 10506 Comm: bundle Tainted: G D 5.13.0-27-generic #29~20.04.1-Ubuntu Jan 28 05:44:27 server kernel: [44106.690420] Hardware name: Hetzner vServer, BIOS 20171111 11/11/2017 Jan 28 05:44:27 server kernel: [44106.690721] RIP: 0010:0x0 Jan 28 05:44:27 server kernel: [44106.690950] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. Jan 28 05:44:27 server kernel: [44106.691260] RSP: 0000:ffffab7302ae7bb8 EFLAGS: 00010282 Jan 28 05:44:27 server kernel: [44106.691529] RAX: 0000000000000000 RBX: ffffab7302ae7cf0 RCX: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.691847] RDX: 0000000000000000 RSI: fffff4c485056680 RDI: ffff9f0924b43400 Jan 28 05:44:27 server kernel: [44106.692181] RBP: ffffab7302ae7c20 R08: 000000000000001c R09: 00000000000009d8 Jan 28 05:44:27 server kernel: [44106.692506] R10: ffffab7302ae7b88 R11: 0000000000000003 R12: fffff4c485056680 Jan 28 05:44:27 server kernel: [44106.692827] R13: ffffab7302ae7c58 R14: 0000000000000000 R15: ffffffff8aa411c0 Jan 28 05:44:27 server kernel: [44106.693148] FS: 00007fd6504bdf80(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000 Jan 28 05:44:27 server kernel: [44106.693558] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 28 05:44:27 server kernel: [44106.693838] CR2: ffffffffffffffd6 CR3: 000000021fa48001 CR4: 00000000007706e0 Jan 28 05:44:27 server kernel: [44106.694154] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.694476] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 28 05:44:27 server kernel: [44106.694798] PKRU: 55555554 Jan 28 05:44:27 server kernel: [44106.694992] Call Trace: Jan 28 05:44:27 server kernel: [44106.695213] read_pages+0x1fb/0x280 Jan 28 05:44:27 server kernel: [44106.695487] ? add_to_page_cache_lru+0x78/0xd0 Jan 28 05:44:27 server kernel: [44106.695745] page_cache_ra_unbounded+0x146/0x1f0 Jan 28 05:44:27 server kernel: [44106.696057] do_page_cache_ra+0x3d/0x40 Jan 28 05:44:27 server kernel: [44106.696286] filemap_fault+0x4f4/0x9b0 Jan 28 05:44:27 server kernel: [44106.696506] ? do_set_pte+0xc8/0x140 Jan 28 05:44:27 server kernel: [44106.696736] ext4_filemap_fault+0x32/0x50 Jan 28 05:44:27 server kernel: [44106.696970] __do_fault+0x3e/0xc0 Jan 28 05:44:27 server kernel: [44106.697180] do_fault+0x1ea/0x440 Jan 28 05:44:27 server kernel: [44106.697399] __handle_mm_fault+0x619/0x8e0 Jan 28 05:44:27 server kernel: [44106.697642] handle_mm_fault+0xda/0x2b0 Jan 28 05:44:27 server kernel: [44106.697868] do_user_addr_fault+0x1bb/0x650 Jan 28 05:44:27 server kernel: [44106.698109] exc_page_fault+0x7d/0x170 Jan 28 05:44:27 server kernel: [44106.698347] ? asm_exc_page_fault+0x8/0x30 Jan 28 05:44:27 server kernel: [44106.698583] asm_exc_page_fault+0x1e/0x30 Jan 28 05:44:27 server kernel: [44106.698810] RIP: 0033:0x7fd65055a68c Jan 28 05:44:27 server kernel: [44106.699041] Code: d1 48 8d 14 c8 31 c9 eb 21 0f 1f 44 00 00 81 fe 50 e5 74 64 0f 84 74 01 00 00 83 fe 02 48 0f 44 c8 48 83 c0 38 48 39 c2 74 3c <8b> 30 83 fe 01 75 dd 48 8b 70 10 4c 8b 0b 4c 01 c6 49 39 f1 72 e1 Jan 28 05:44:27 server kernel: [44106.699812] RSP: 002b:00007fd64fa70b70 EFLAGS: 00010246 Jan 28 05:44:27 server kernel: [44106.700085] RAX: 00007fd64f80b040 RBX: 00007fd64fa70cb0 RCX: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.700400] RDX: 00007fd64f80b2a8 RSI: 0000000000000000 RDI: 0000000000000040 Jan 28 05:44:27 server kernel: [44106.700715] RBP: 0000000000000079 R08: 00007fd64f80b000 R09: 00007fd640d5e140 Jan 28 05:44:27 server kernel: [44106.701033] R10: 0000000000000000 R11: 0000000000000000 R12: 00007fd6505622d0 Jan 28 05:44:27 server kernel: [44106.701351] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 Jan 28 05:44:27 server kernel: [44106.701678] Modules linked in: xt_multiport xt_nat xt_addrtype xt_mark xt_comment ipt_REJECT nf_reject_ipv4 xt_set ip_set_hash_ip veth xt_MASQUERADE xt_state xt_conntrack xt_tcpudp ip_set_hash_net ip_set nfnetlink ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter overlay input_leds joydev serio_raw bridge stp llc sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel xhci_pci crypto_simd psmouse cryptd xhci_pci_renesas virtio_net net_failover virtio_scsi failover floppy Jan 28 05:44:27 server kernel: [44106.704724] CR2: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.704954] ---[ end trace 18bf93f57f5e5c7e ]--- Jan 28 05:44:27 server kernel: [44106.705198] RIP: 0010:0x0 Jan 28 05:44:27 server kernel: [44106.705396] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. Jan 28 05:44:27 server kernel: [44106.705715] RSP: 0000:ffffab7301c57bb8 EFLAGS: 00010286 Jan 28 05:44:27 server kernel: [44106.705984] RAX: 0000000000000000 RBX: ffffab7301c57cf0 RCX: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.706303] RDX: 0000000000000000 RSI: fffff4c486dfaa00 RDI: ffff9f0ac87b5a00 Jan 28 05:44:27 server kernel: [44106.706617] RBP: ffffab7301c57c20 R08: 0000000000000098 R09: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.706943] R10: ffffab7301c57b88 R11: 0000000000003327 R12: fffff4c486dfaa00 Jan 28 05:44:27 server kernel: [44106.707281] R13: ffffab7301c57c58 R14: 0000000000000000 R15: ffffffff8aa411c0 Jan 28 05:44:27 server kernel: [44106.707609] FS: 00007fd6504bdf80(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000 Jan 28 05:44:27 server kernel: [44106.708053] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 28 05:44:27 server kernel: [44106.708335] CR2: ffffffffffffffd6 CR3: 000000021fa48001 CR4: 00000000007706e0 Jan 28 05:44:27 server kernel: [44106.708657] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 28 05:44:27 server kernel: [44106.709061] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 28 05:44:27 server kernel: [44106.709503] PKRU: 55555554 ``` ``` Jan 28 11:00:26 server kernel: [63065.536851] general protection fault, probably for non-canonical address 0x3f3fd247e88d44f4: 0000 [#3] SMP PTI Jan 28 11:00:26 server kernel: [63065.537694] CPU: 1 PID: 409741 Comm: thread_pool.rb* Tainted: G D 5.13.0-27-generic #29~20.04.1-Ubuntu Jan 28 11:00:26 server kernel: [63065.538385] Hardware name: Hetzner vServer, BIOS 20171111 11/11/2017 Jan 28 11:00:26 server kernel: [63065.538785] RIP: 0010:rwsem_down_write_slowpath+0x5ad/0x5f0 Jan 28 11:00:26 server kernel: [63065.539097] Code: a8 02 75 a9 49 8d 57 08 48 89 c1 48 83 c9 02 f0 48 0f b1 0a 74 97 a8 01 74 93 a8 02 74 ea eb 8d f0 49 83 0f 02 e9 3a fb ff ff <8b> 42 34 85 c0 0f 84 b1 fa ff ff 8b 7a 48 48 31 c0 0f 1f 40 00 84 Jan 28 11:00:26 server kernel: [63065.539886] RSP: 0018:ffffab73015f7ae0 EFLAGS: 00010246 Jan 28 11:00:26 server kernel: [63065.540184] RAX: 3f3fd247e88d44c0 RBX: ffff9f09b63a19c0 RCX: ffff9f09b63a19c0 Jan 28 11:00:26 server kernel: [63065.540501] RDX: 3f3fd247e88d44c0 RSI: 0000000000000002 RDI: 0000000000000000 Jan 28 11:00:26 server kernel: [63065.540864] RBP: ffffab73015f7b90 R08: 00007fd63db86000 R09: ffffffff89aaf400 Jan 28 11:00:26 server kernel: [63065.541182] R10: ffff9f0a11747540 R11: 0000000000000001 R12: ffff9f0a02815598 Jan 28 11:00:26 server kernel: [63065.541531] R13: ffff9f0ad3019700 R14: ffff9f0a02815598 R15: ffff9f0a02815598 Jan 28 11:00:26 server kernel: [63065.541877] FS: 0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000 Jan 28 11:00:26 server kernel: [63065.542303] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 28 11:00:26 server kernel: [63065.542579] CR2: 00007f80b798c000 CR3: 000000010d5f2005 CR4: 00000000007706e0 Jan 28 11:00:26 server kernel: [63065.542935] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 28 11:00:26 server kernel: [63065.543264] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 28 11:00:26 server kernel: [63065.543588] PKRU: 55555554 Jan 28 11:00:26 server kernel: [63065.543787] Call Trace: Jan 28 11:00:26 server kernel: [63065.543992] ? __mod_memcg_state+0x2f/0x40 Jan 28 11:00:26 server kernel: [63065.544302] ? unlink_anon_vmas+0x153/0x1c0 Jan 28 11:00:26 server kernel: [63065.544638] down_write+0x41/0x50 Jan 28 11:00:26 server kernel: [63065.544955] unlink_file_vma+0x33/0x60 Jan 28 11:00:26 server kernel: [63065.545273] free_pgtables+0x9b/0xf0 Jan 28 11:00:26 server kernel: [63065.545574] exit_mmap+0xbe/0x1f0 Jan 28 11:00:26 server kernel: [63065.545877] mmput+0x5d/0x130 Jan 28 11:00:26 server kernel: [63065.546165] do_exit+0x324/0xaf0 Jan 28 11:00:26 server kernel: [63065.546478] ? hrtimer_init_sleeper+0x80/0x80 Jan 28 11:00:26 server kernel: [63065.546818] do_group_exit+0x43/0xb0 Jan 28 11:00:26 server kernel: [63065.547117] get_signal+0x171/0x880 Jan 28 11:00:26 server kernel: [63065.547442] arch_do_signal_or_restart+0xf2/0x290 Jan 28 11:00:26 server kernel: [63065.547807] ? _copy_from_user+0x2b/0x60 Jan 28 11:00:26 server kernel: [63065.548174] exit_to_user_mode_prepare+0x12f/0x1c0 Jan 28 11:00:26 server kernel: [63065.548569] syscall_exit_to_user_mode+0x27/0x50 Jan 28 11:00:26 server kernel: [63065.548975] do_syscall_64+0x6e/0xb0 Jan 28 11:00:26 server kernel: [63065.549341] ? do_syscall_64+0x6e/0xb0 Jan 28 11:00:26 server kernel: [63065.549705] ? syscall_exit_to_user_mode+0x27/0x50 Jan 28 11:00:26 server kernel: [63065.550108] ? do_syscall_64+0x6e/0xb0 Jan 28 11:00:26 server kernel: [63065.550480] ? sysvec_apic_timer_interrupt+0x4e/0x90 Jan 28 11:00:26 server kernel: [63065.550876] ? asm_sysvec_apic_timer_interrupt+0xa/0x20 Jan 28 11:00:26 server kernel: [63065.551303] entry_SYSCALL_64_after_hwframe+0x44/0xae Jan 28 11:00:26 server kernel: [63065.551715] RIP: 0033:0x7fd6505357b1 Jan 28 11:00:26 server kernel: [63065.564753] Code: Unable to access opcode bytes at RIP 0x7fd650535787. Jan 28 11:00:26 server kernel: [63065.565194] RSP: 002b:00007fd6182fce20 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca Jan 28 11:00:26 server kernel: [63065.565757] RAX: fffffffffffffdfc RBX: 00007fd64245bd3c RCX: 00007fd6505357b1 Jan 28 11:00:26 server kernel: [63065.566196] RDX: 0000000000000000 RSI: 0000000000000089 RDI: 00007fd64245bd54 Jan 28 11:00:26 server kernel: [63065.566646] RBP: 00007fd64245bd28 R08: 0000000000000000 R09: 00000000ffffffff Jan 28 11:00:26 server kernel: [63065.567094] R10: 00007fd6182fcf20 R11: 0000000000000246 R12: 00007fd64245bd4c Jan 28 11:00:26 server kernel: [63065.567417] R13: 00007fd650025010 R14: 00007fd64245bd54 R15: 00007fd6182fce70 Jan 28 11:00:26 server kernel: [63065.567764] Modules linked in: xt_multiport xt_nat xt_addrtype xt_mark xt_comment ipt_REJECT nf_reject_ipv4 xt_set ip_set_hash_ip veth xt_MASQUERADE xt_state xt_conntrack xt_tcpudp ip_set_hash_net ip_set nfnetlink ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter overlay input_leds joydev serio_raw bridge stp llc sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel xhci_pci crypto_simd psmouse cryptd xhci_pci_renesas virtio_net net_failover virtio_scsi failover floppy Jan 28 11:00:26 server kernel: [63065.571499] ---[ end trace 18bf93f57f5e5c7f ]--- Jan 28 11:00:26 server kernel: [63065.571833] RIP: 0010:0x0 Jan 28 11:00:26 server kernel: [63065.572055] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. Jan 28 11:00:26 server kernel: [63065.572454] RSP: 0000:ffffab7301c57bb8 EFLAGS: 00010286 Jan 28 11:00:26 server kernel: [63065.572767] RAX: 0000000000000000 RBX: ffffab7301c57cf0 RCX: 0000000000000000 Jan 28 11:00:26 server kernel: [63065.573220] RDX: 0000000000000000 RSI: fffff4c486dfaa00 RDI: ffff9f0ac87b5a00 Jan 28 11:00:26 server kernel: [63065.573541] RBP: ffffab7301c57c20 R08: 0000000000000098 R09: 0000000000000000 Jan 28 11:00:26 server kernel: [63065.573869] R10: ffffab7301c57b88 R11: 0000000000003327 R12: fffff4c486dfaa00 Jan 28 11:00:26 server kernel: [63065.574233] R13: ffffab7301c57c58 R14: 0000000000000000 R15: ffffffff8aa411c0 Jan 28 11:00:26 server kernel: [63065.574631] FS: 0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000 Jan 28 11:00:26 server kernel: [63065.575235] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 28 11:00:26 server kernel: [63065.575646] CR2: ffffffffffffffd6 CR3: 000000010d5f2005 CR4: 00000000007706e0 Jan 28 11:00:26 server kernel: [63065.576099] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 28 11:00:26 server kernel: [63065.576547] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 28 11:00:26 server kernel: [63065.576991] PKRU: 55555554 Jan 28 11:00:26 server kernel: [63065.577245] Fixing recursive fault but reboot is needed! ``` ``` Jan 28 11:01:32 server kernel: [63131.986855] general protection fault, probably for non-canonical address 0x3f3fd247e88d44f4: 0000 [#4] SMP PTI Jan 28 11:01:32 server kernel: [63131.993305] CPU: 1 PID: 412842 Comm: scheduler.rb:73 Tainted: G D 5.13.0-27-generic #29~20.04.1-Ubuntu Jan 28 11:01:32 server kernel: [63131.993804] Hardware name: Hetzner vServer, BIOS 20171111 11/11/2017 Jan 28 11:01:32 server kernel: [63131.994110] RIP: 0010:rwsem_down_write_slowpath+0x5ad/0x5f0 Jan 28 11:01:32 server kernel: [63131.994424] Code: a8 02 75 a9 49 8d 57 08 48 89 c1 48 83 c9 02 f0 48 0f b1 0a 74 97 a8 01 74 93 a8 02 74 ea eb 8d f0 49 83 0f 02 e9 3a fb ff ff <8b> 42 34 85 c0 0f 84 b1 fa ff ff 8b 7a 48 48 31 c0 0f 1f 40 00 84 Jan 28 11:01:32 server kernel: [63131.995189] RSP: 0018:ffffab730207fab0 EFLAGS: 00010246 Jan 28 11:01:32 server kernel: [63131.995464] RAX: 3f3fd247e88d44c0 RBX: ffff9f09a8afedd0 RCX: ffff9f09a8afedd0 Jan 28 11:01:32 server kernel: [63131.995784] RDX: 3f3fd247e88d44c0 RSI: 0000000000000002 RDI: 0000000000000000 Jan 28 11:01:32 server kernel: [63131.996175] RBP: ffffab730207fb60 R08: 00007fd63db86000 R09: ffffffff89aaf400 Jan 28 11:01:32 server kernel: [63131.996603] R10: ffff9f0a0d5bc340 R11: 0000000000000001 R12: ffff9f0a02815598 Jan 28 11:01:32 server kernel: [63131.996971] R13: ffff9f0ad3019700 R14: ffff9f0a02815598 R15: ffff9f0a02815598 Jan 28 11:01:32 server kernel: [63131.997367] FS: 0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000 Jan 28 11:01:32 server kernel: [63131.997909] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 28 11:01:32 server kernel: [63131.998295] CR2: 00007fd63e25dfc0 CR3: 0000000109124004 CR4: 00000000007706e0 Jan 28 11:01:32 server kernel: [63131.998735] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 28 11:01:32 server kernel: [63131.999178] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 28 11:01:32 server kernel: [63131.999616] PKRU: 55555554 Jan 28 11:01:32 server kernel: [63131.999893] Call Trace: Jan 28 11:01:32 server kernel: [63132.000183] ? __mod_memcg_state+0x2f/0x40 Jan 28 11:01:32 server kernel: [63132.000508] ? unlink_anon_vmas+0x153/0x1c0 Jan 28 11:01:32 server kernel: [63132.000802] down_write+0x41/0x50 Jan 28 11:01:32 server kernel: [63132.001089] unlink_file_vma+0x33/0x60 Jan 28 11:01:32 server kernel: [63132.001378] free_pgtables+0x9b/0xf0 Jan 28 11:01:32 server kernel: [63132.001705] exit_mmap+0xbe/0x1f0 Jan 28 11:01:32 server kernel: [63132.002018] mmput+0x5d/0x130 Jan 28 11:01:32 server kernel: [63132.002288] do_exit+0x324/0xaf0 Jan 28 11:01:32 server kernel: [63132.002573] do_group_exit+0x43/0xb0 Jan 28 11:01:32 server kernel: [63132.002871] get_signal+0x171/0x880 Jan 28 11:01:32 server kernel: [63132.003190] arch_do_signal_or_restart+0xf2/0x290 Jan 28 11:01:32 server kernel: [63132.003516] exit_to_user_mode_prepare+0x12f/0x1c0 Jan 28 11:01:32 server kernel: [63132.003807] syscall_exit_to_user_mode+0x27/0x50 Jan 28 11:01:32 server kernel: [63132.004153] do_syscall_64+0x6e/0xb0 Jan 28 11:01:32 server kernel: [63132.004413] ? syscall_exit_to_user_mode+0x27/0x50 Jan 28 11:01:32 server kernel: [63132.004741] ? do_syscall_64+0x6e/0xb0 Jan 28 11:01:32 server kernel: [63132.004999] ? syscall_exit_to_user_mode+0x27/0x50 Jan 28 11:01:32 server kernel: [63132.005261] ? do_syscall_64+0x6e/0xb0 Jan 28 11:01:32 server kernel: [63132.005487] ? do_syscall_64+0x6e/0xb0 Jan 28 11:01:32 server kernel: [63132.005717] ? do_syscall_64+0x6e/0xb0 Jan 28 11:01:32 server kernel: [63132.005944] ? asm_exc_page_fault+0x8/0x30 Jan 28 11:01:32 server kernel: [63132.006202] entry_SYSCALL_64_after_hwframe+0x44/0xae Jan 28 11:01:32 server kernel: [63132.006471] RIP: 0033:0x7fd650535376 Jan 28 11:01:32 server kernel: [63132.006700] Code: Unable to access opcode bytes at RIP 0x7fd65053534c. Jan 28 11:01:32 server kernel: [63132.007003] RSP: 002b:00007fd6174f93f0 EFLAGS: 00000282 ORIG_RAX: 00000000000000ca Jan 28 11:01:32 server kernel: [63132.007417] RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 00007fd650535376 Jan 28 11:01:32 server kernel: [63132.007747] RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fd6193d9094 Jan 28 11:01:32 server kernel: [63132.008080] RBP: 00007fd6193d9068 R08: 0000000000000000 R09: 0000000000000004 Jan 28 11:01:32 server kernel: [63132.008420] R10: 0000000000000000 R11: 0000000000000282 R12: 00007fd6193d908c Jan 28 11:01:32 server kernel: [63132.008735] R13: 00007fd650025010 R14: 00007fd6174f9430 R15: 00007fd6193d9094 Jan 28 11:01:32 server kernel: [63132.009056] Modules linked in: xt_multiport xt_nat xt_addrtype xt_mark xt_comment ipt_REJECT nf_reject_ipv4 xt_set ip_set_hash_ip veth xt_MASQUERADE xt_state xt_conntrack xt_tcpudp ip_set_hash_net ip_set nfnetlink ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter overlay input_leds joydev serio_raw bridge stp llc sch_fq_codel drm ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel xhci_pci crypto_simd psmouse cryptd xhci_pci_renesas virtio_net net_failover virtio_scsi failover floppy Jan 28 11:01:32 server kernel: [63132.012499] ---[ end trace 18bf93f57f5e5c80 ]--- Jan 28 11:01:32 server kernel: [63132.012753] RIP: 0010:0x0 Jan 28 11:01:32 server kernel: [63132.012960] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. Jan 28 11:01:32 server kernel: [63132.013340] RSP: 0000:ffffab7301c57bb8 EFLAGS: 00010286 Jan 28 11:01:32 server kernel: [63132.013722] RAX: 0000000000000000 RBX: ffffab7301c57cf0 RCX: 0000000000000000 Jan 28 11:01:32 server kernel: [63132.014151] RDX: 0000000000000000 RSI: fffff4c486dfaa00 RDI: ffff9f0ac87b5a00 Jan 28 11:01:32 server kernel: [63132.014596] RBP: ffffab7301c57c20 R08: 0000000000000098 R09: 0000000000000000 Jan 28 11:01:32 server kernel: [63132.015066] R10: ffffab7301c57b88 R11: 0000000000003327 R12: fffff4c486dfaa00 Jan 28 11:01:32 server kernel: [63132.015504] R13: ffffab7301c57c58 R14: 0000000000000000 R15: ffffffff8aa411c0 Jan 28 11:01:32 server kernel: [63132.015851] FS: 0000000000000000(0000) GS:ffff9f0b2bf00000(0000) knlGS:0000000000000000 Jan 28 11:01:32 server kernel: [63132.016267] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 28 11:01:32 server kernel: [63132.016547] CR2: ffffffffffffffd6 CR3: 0000000109124004 CR4: 00000000007706e0 Jan 28 11:01:32 server kernel: [63132.016913] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jan 28 11:01:32 server kernel: [63132.017247] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jan 28 11:01:32 server kernel: [63132.017588] PKRU: 55555554 Jan 28 11:01:32 server kernel: [63132.017848] Fixing recursive fault but reboot is needed! ``` </details> Ve výpisu jsou zmíněny procesy, resp. vlákna `bundle`, `thread_pool.rb` a `scheduler.rb`. Všechny by měly být spouštěny webovým serverem Puma, který je psaný v Ruby (proto ta vlákna s *.rb na konci), který GitLab používá. Ve výpisu stromu procesů jsou vidět zombie procesy `bundle`, nicméně ta zombifikace bude nejspíše symptom, nikoliv příčina. Dále jsou ve výpisu procesů také vidět různé procesy čekající na diskové I/O, které s výše uvedenými nemusí vždy souviset. Zdá se, že jde o procesy, které prováděly diskové operace ve chvíli kdy ke kernel bugu došlo. Při minulém incidentu mezi nimi byl například i postgres nebo procesy Onlyoffice běžící v odděleném kontejneru. Teď vidím ssh daemona GitLabu. Při obou incidentech byl ve výpisu zachycen i proces pro vytváření záloh WordPressu, rep. jejich kompresi (nutno podotknout, že `tar` v tomto případě data z disku pouze čte a předává je rourou `gzip` procesu, který je komprimuje a zapisuje zpět na disk. Viset ale zůstal `tar`. Vzhledem k neobvyklosti problému to ale nemusí nic znamenat). A taktéž je ve výpisu vidět podproces jádra pro zkompaktnění paměťových stránek ([článek s popisem](https://lwn.net/Articles/368869/)), který čeká na I/O. <details><summary>Výpisy stromů procesů</summary> ``` 2271 ? Ssl 0:51 /usr/libexec/podman/conmon --api-version 1 -c c2e6acfa470734e8fb950fef2acc928761c6d862c04b4f0e07eb0d6ac4fbebd4 -u c2e6acfa470734e 2276 ? Ss 0:00 \_ /bin/bash /assets/wrapper 2983 ? S 0:05 \_ runsvdir -P /opt/gitlab/service log: ...... 4115 ? Ss 0:00 | \_ runsv puma 4117 ? Ssl 2:04 | | \_ puma 5.5.2 (unix:///var/opt/gitlab/gitlab-rails/sockets/gitlab.socket,tcp://127.0.0.1:8080) [gitlab-puma-worker] 409734 ? Zl 0:01 | | | \_ [bundle] <defunct> 412712 ? Zl 0:00 | | | \_ [bundle] <defunct> ``` ``` 2271 ? Ssl 0:51 /usr/libexec/podman/conmon --api-version 1 -c c2e6acfa470734e8fb950fef2acc928761c6d862c04b4f0e07eb0d6ac4fbebd4 -u c2e6acfa470734e 2276 ? Ss 0:00 \_ /bin/bash /assets/wrapper 88153 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 0 of 100-200 startups 94373 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 1 of 100-200 startups 98593 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 2 of 100-200 startups 98935 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 3 of 100-200 startups 99031 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 4 of 100-200 startups 99276 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 5 of 100-200 startups 99561 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 6 of 100-200 startups 99676 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 7 of 100-200 startups 99722 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 8 of 100-200 startups 99739 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 9 of 100-200 startups 99777 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 10 of 100-200 startups 103683 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 11 of 100-200 startups 106965 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 12 of 100-200 startups 107038 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 13 of 100-200 startups 107294 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 14 of 100-200 startups 107364 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 15 of 100-200 startups 107431 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 16 of 100-200 startups 108648 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 17 of 100-200 startups 108718 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 18 of 100-200 startups 108989 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 19 of 100-200 startups 111469 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 20 of 100-200 startups 111673 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 21 of 100-200 startups 111792 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 22 of 100-200 startups 113582 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 23 of 100-200 startups 114846 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 24 of 100-200 startups 114978 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 25 of 100-200 startups 114980 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 26 of 100-200 startups 115831 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 27 of 100-200 startups 116243 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 28 of 100-200 startups 117174 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 29 of 100-200 startups 122585 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 30 of 100-200 startups 127300 ? D 0:00 \_ sshd: /usr/sbin/sshd -D -f /assets/sshd_config -e [listener] 31 of 100-200 startups ``` ``` 461 ? Ss 0:02 /usr/sbin/cron -f 703772 ? S 0:00 \_ /usr/sbin/CRON -f 703775 ? Ss 0:00 \_ /bin/sh -c /root/backup.sh >/dev/null 703779 ? S 0:00 \_ /bin/sh /root/backup.sh 703896 ? D 0:06 \_ tar cf - wordpress 703897 ? S 1:01 \_ gzip -9 ``` ``` 30 ? D 1:17 \_ [kcompactd0] ``` </details> Poslední jmenovaný je vzhledem k vytížení systému hlavním podezřelým. Systém většinu času operuje na hranici svých možností, co se zaplnění RAM a swapu týče, a kernel bugy naznačují, že k problému dochází právě při pokusu o přístup či uvolnění paměti. --- **Pokusy o zmírnění dopadu** **1)** Ve stávající situaci byl SSH port GitLabu otevřen pro přístup do celého světa, během čehož byl bombardován pokusy o přístup s neplatnými údaji, které byly odmítány a při opakování promptně zaříznuty fail2banem. Omezil jsem přístup pouze na rozsahy IP adres používané ISP v Česku. Kdyby se někdy outsourcovaly nějaké věci kolem kódu v GitLabu do Indie nebo na jiné Slovensko, bude potřeba ta omezení upravit. Nečekám že by tato akce měla jakýkoliv dopad na vytížení, protože SSH daemon je oproti některým ostatním službám běžícím na server naprosto titěrný, ale není důvod to neudělat. Obzvlášť když byl SSH daemon při jednom z incidentů postižen. **2)** ClamAV po startu drží celou databázi antivirových vzorků v paměti, aby s nimi mohl bleskurychle pracovat a nepotřeboval dodatečné přístupy na disk. Databáze obsahuje cca 8,7 milionu vzorků a rozbalená a zaindexovaná zabírá cca 1 GB v paměti RAM. Vzhledem k tomu, že používáme i virové databáze třetích stran, včetně takových které reagují na nové hrozby dynamicky, je pro maximální možnou ochranu potřeba jejich databáze obnovovat v řádu minut. Při obnovení databáze dochází k jejímu nahrání do paměti zatímco předchozí verze v paměti stále existuje a pracuje se s ní. Každých 5 minut (interval obnovy) tedy využití RAM ClamAV špičkově vyskočí na dvojnásobek a drží se tam po dobu cca 30 sekund, dokud se obnovená nová databáze nenačte a stará kopie nezahodí, čímž dojde k uvolnění paměti. Nastavil jsem tedy v tuto chvíli `ConcurrentDatabaseReload no` v `/etc/clamav/clamd.conf`, což způsobí, že ClamAV nebude uchovávat kopii databáze v paměti během obnovy, ale místo toho nejprve starou databázi zahodí a pak teprve načte novou. To by mělo poměrně značně snížit fluktuace využité paměti, za cenu toho, že doručení některých mailů může být zdrženo v řádu jednotek minut. Trvalé řešení, které nejprve musím navrhnout a otestovat, je mít dvě souběžné instance ClamAV. Jednu s hlavní databází, která se obnovuje pouze jednou za den, a druhou instanci s tou "online" databází, která je podstatně menší a může se tak obnovovat častěji a rychleji než v současnosti.
Podhorecky commented 2022-01-29 19:09:23 +01:00 (Migrated from git.spotter.cz)

wow... mno pěkné.
jen pro info, z mé činnosti mohlo před časem přistát na NextCloud několik desítek, možná stovek MB souborů, ale to snad nebylo mnoho. Také jsem před pár dny updatoval novou verzi OnlyOffice, to bylo pak vidět, že při prvním spuštění dokumentu mu chvilku trvalo, než si to znova OO natahal do paměti. Nadále NC a OO běží vpořádku.
Nedávno jsem také updatoval pluginy a šablony ve WordPressu, protože přišla nová verze WP... ovšem samotný WP jsem ještě neupdatoval. A nespěchám na to.

Kdybyste vyhodnotil že by prospělo odmazat uživatelská data, tak něco smažu, kdyby to měla být nějaká temp data ze serveru, tak klidně smažte jak uznáte. U procesů nevím, asi by šlo vypnout něco z volitelných rozšíření NextCloudu. Případné doručování mailů s minutovým zpožděním mi vůbec nevadí. Další řešení výhledově, jak uznáte.
V blízké době nikdo další na Gitlab nepřistupuje. Díky!

wow... mno pěkné. jen pro info, z mé činnosti mohlo před časem přistát na NextCloud několik desítek, možná stovek MB souborů, ale to snad nebylo mnoho. Také jsem před pár dny updatoval novou verzi OnlyOffice, to bylo pak vidět, že při prvním spuštění dokumentu mu chvilku trvalo, než si to znova OO natahal do paměti. Nadále NC a OO běží vpořádku. Nedávno jsem také updatoval pluginy a šablony ve WordPressu, protože přišla nová verze WP... ovšem samotný WP jsem ještě neupdatoval. A nespěchám na to. Kdybyste vyhodnotil že by prospělo odmazat uživatelská data, tak něco smažu, kdyby to měla být nějaká temp data ze serveru, tak klidně smažte jak uznáte. U procesů nevím, asi by šlo vypnout něco z volitelných rozšíření NextCloudu. Případné doručování mailů s minutovým zpožděním mi vůbec nevadí. Další řešení výhledově, jak uznáte. V blízké době nikdo další na Gitlab nepřistupuje. Díky!
Disassembler commented 2022-01-30 11:02:22 +01:00 (Migrated from git.spotter.cz)

Mno, tak to nepomohlo.

Takže dále zkouším

  • Použít starší kernel 5.11.0-44 namísto aktuálního 5.13.0-27
  • Zvětšit swap z 2 GB na 4 GB
  • Nastavit vm.swappiness = 20 místo výchozích 60, aby kernel swap používal v méně případech
Mno, tak to nepomohlo. Takže dále zkouším - Použít starší kernel 5.11.0-44 namísto aktuálního 5.13.0-27 - Zvětšit swap z 2 GB na 4 GB - Nastavit `vm.swappiness = 20` místo výchozích 60, aby kernel swap používal v méně případech
Disassembler commented 2022-01-31 00:02:57 +01:00 (Migrated from git.spotter.cz)

Nerad bych to zakřikl, ale současný stav se mi zatím líbí. Pokud to bude bez problémů držet ještě v úterý, zkusím vrátit původní verzi kernelu a nastavení swapu bych ponechal bez dalších změn. Ty 4 GB se zdají být adekvátní.

Mezitím jsem implementoval zmíněnou změnu v ClamAV. Nyní tedy na serveru jedou dvě instance antivirové služby. První pracuje s databázemi udržovanými přímo ClamAV a podružnými databázemi třetích stran aktualizovanými pouze párkrát denně. Reload takové databáze proběhne nejvýše jednou za hodinu a to pouze pokud došlo ke změnám v definicích. Druhá instance pak obsluhuje pouze onu konstantně se měnící adaptivní databázi. Celá tato instance zabírá cca 17 MB RAM, samotná databáze cca polovinu z toho, a její reload proběhne za méně než vteřinu, takže místo původního intervalu jednou za pět minut se nyní aktualizuje každou minutu.

Nevím proč mě něco takového nenapadlo dřív. Když jsem dva roky zpátky načítání té adaptivní databáze implementoval, viděl jsem, že to výkonnostně není žádná bomba, což byl taky důvod proč jsem zvolil interval pěti minut i přesto, že správce té databáze doporučuje aktualizovat po minutě. Po pěti už to bylo "good enough". Ostatní servery které spravuji jsou dimenzované dostatečně a problémy to nezpůsobuje, ale ten váš je nacpaný jak klaunovské auto, takže tam se taková optimalizace určitě hodí.

Nerad bych to zakřikl, ale současný stav se mi zatím líbí. Pokud to bude bez problémů držet ještě v úterý, zkusím vrátit původní verzi kernelu a nastavení swapu bych ponechal bez dalších změn. Ty 4 GB se zdají být adekvátní. Mezitím jsem implementoval zmíněnou změnu v ClamAV. Nyní tedy na serveru jedou dvě instance antivirové služby. První pracuje s databázemi udržovanými přímo ClamAV a podružnými databázemi třetích stran aktualizovanými pouze párkrát denně. Reload takové databáze proběhne nejvýše jednou za hodinu a to pouze pokud došlo ke změnám v definicích. Druhá instance pak obsluhuje pouze onu konstantně se měnící adaptivní databázi. Celá tato instance zabírá cca 17 MB RAM, samotná databáze cca polovinu z toho, a její reload proběhne za méně než vteřinu, takže místo původního intervalu jednou za pět minut se nyní aktualizuje každou minutu. Nevím proč mě něco takového nenapadlo dřív. Když jsem dva roky zpátky načítání té adaptivní databáze implementoval, viděl jsem, že to výkonnostně není žádná bomba, což byl taky důvod proč jsem zvolil interval pěti minut i přesto, že správce té databáze doporučuje aktualizovat po minutě. Po pěti už to bylo "*good enough*". Ostatní servery které spravuji jsou dimenzované dostatečně a problémy to nezpůsobuje, ale ten váš je nacpaný jak klaunovské auto, takže tam se taková optimalizace určitě hodí.
Disassembler commented 2022-02-01 13:35:42 +01:00 (Migrated from git.spotter.cz)

Dobrý den,
vypadá to, že Hetzner asi nevydržel kvokání, takže to vzdal úplně.
žádný spěch, za mne neni nic akutního.
Pokud usvědčíte pachatele a bude nutná redukce tak se holt přizpůsobím situaci.

Anojofurt. Však jsem říkal, že když vydrží do úterka, tak ho rozbiju sám, abyste si nezvykal, že to máte zas stabilní.

Jako viník byl identifikován kernel 5.13. S tou 5.11 to frčelo dva dny bez náznaků problému. Dopoledne jsem vrátil zpět tu 5.13 aniž bych měnil cokoliv jiného a do dvou hodin to šlo na tlamu.

Takže teď jsem tam zpátky vrátil kernel 5.11 a zamrazil jej, aby se neupdatoval. Taky jsem ukradl zpátky 2 GB swapu, protože ty předchozí 2 GB by podle všeho měly stačit, zvlášť s tou úpravou vm.swappiness. Teď už to zas nechám nějakou dobu být. Uvidím, jestli se mu nebude o víkendu chtít vyrobit na to nějaký bugreport Canonicalu, ale to bych Vám dal vědět ještě předtím než to zas rozbiju.

> Dobrý den, > vypadá to, že Hetzner asi nevydržel kvokání, takže to vzdal úplně. > žádný spěch, za mne neni nic akutního. > Pokud usvědčíte pachatele a bude nutná redukce tak se holt přizpůsobím situaci. Anojofurt. Však jsem říkal, že když vydrží do úterka, tak ho rozbiju sám, abyste si nezvykal, že to máte zas stabilní. Jako viník byl identifikován kernel 5.13. S tou 5.11 to frčelo dva dny bez náznaků problému. Dopoledne jsem vrátil zpět tu 5.13 aniž bych měnil cokoliv jiného a do dvou hodin to šlo na tlamu. Takže teď jsem tam zpátky vrátil kernel 5.11 a zamrazil jej, aby se neupdatoval. Taky jsem ukradl zpátky 2 GB swapu, protože ty předchozí 2 GB by podle všeho měly stačit, zvlášť s tou úpravou `vm.swappiness`. Teď už to zas nechám nějakou dobu být. Uvidím, jestli se mu nebude o víkendu chtít vyrobit na to nějaký bugreport Canonicalu, ale to bych Vám dal vědět ještě předtím než to zas rozbiju.
Podhorecky commented 2022-02-01 14:03:17 +01:00 (Migrated from git.spotter.cz)

Děkuji mockrát za všechny kungfu pohyby! uvidíme, věřím že bude ode mne chvíli klid :)
JP

Děkuji mockrát za všechny kungfu pohyby! uvidíme, věřím že bude ode mne chvíli klid :) JP
Podhorecky commented 2022-04-03 11:19:12 +02:00 (Migrated from git.spotter.cz)
tady píší o fixu nějaké kritické chyby, víc tomu nerozumim, nechám na vás... https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released/#static-passwords-inadvertently-set-during-omniauth-based-registration
Disassembler commented 2022-04-03 12:38:12 +02:00 (Migrated from git.spotter.cz)

Zprávu jsem postřehl. OmniAuth nepoužíváme, nicméně ty ostatní zranitelnosti taky nejsou pěkné, takže máme aktualizováno na 14.9.2.

Zprávu jsem postřehl. OmniAuth nepoužíváme, nicméně ty ostatní zranitelnosti taky nejsou pěkné, takže máme aktualizováno na 14.9.2.
Podhorecky commented 2022-04-05 22:52:37 +02:00 (Migrated from git.spotter.cz)

Děkuji za tu aktualizaci, pokoušel jsem se najít kde je v GitLabu info o verzi, ale zatim nevím.

Děkuji za tu aktualizaci, pokoušel jsem se najít kde je v GitLabu info o verzi, ale zatim nevím.
Disassembler commented 2022-04-06 00:11:12 +02:00 (Migrated from git.spotter.cz)

Na stránce s nápovědou - https://git.spotter.cz/help

Na stránce s nápovědou - https://git.spotter.cz/help
Sign in to join this conversation.
No Label
CZ
OSM
pro info
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Spotter-Cluster/Hosting#67
No description provided.