Why does Ubuntu server 16.04.5 stop responding?

Question

linux

The server stops responding to ssh and other requests after a different time, there is such an error in kern.log:

kern.log, syslog

Jul 12 14:02:09 user kernel: [328866.431527] apport[3620]: segfault at 518a8d18 ip 0000000000594321 sp 00000000518a8d20 error 6 in python3.5[400000+3aa000]
Jul 12 14:02:09 user kernel: [328866.431555] Process 3620(apport) has RLIMIT_CORE set to 1
Jul 12 14:02:09 user kernel: [328866.431558] Aborting core
Jul 12 14:02:17 user kernel: [328873.680673] stack segment: 0000 [#1] SMP
Jul 12 14:02:17 user kernel: [328873.680715] Modules linked in: arc4 md4 nls_utf8 cifs ccm fscache xt_multiport xt_nat xt_tcpudp veth ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack br_netfilter bridge stp llc aufs sctp overlay ppdev serio_raw 8250_fintek lpc_ich parport_pc parport mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear raid1 i915 video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops 8139too drm 8139cp mii pata_acpi floppy fjes
Jul 12 14:02:17 user kernel: [328873.681297] CPU: 1 PID: 3636 Comm: apache2 Not tainted 4.4.0-131-generic #157-Ubuntu
Jul 12 14:02:17 user kernel: [328873.681337] Hardware name: Biostar 945GZ Micro 775 SE/945GZ Micro 775 SE, BIOS 6.00 PG 01/23/2007
Jul 12 14:02:17 user kernel: [328873.681382] task: ffff8800776e3fc0 ti: ffff880067014000 task.ti: ffff880067014000
Jul 12 14:02:17 user kernel: [328873.681420] RIP: 0010:[] [] anon_vma_interval_tree_remove+0x18d/0x250
Jul 12 14:02:17 user kernel: [328873.681475] RSP: 0018:ffff880067017b78 EFLAGS: 00010246
Jul 12 14:02:17 user kernel: [328873.681502] RAX: 0000000000000000 RBX: ffff880013b36700 RCX: 0000000000000000
Jul 12 14:02:17 user kernel: [328873.681538] RDX: 0000000000000001 RSI: ffff880017b62fe0 RDI: ffff880013b36700
Jul 12 14:02:17 user kernel: [328873.681574] RBP: ffff880067017b78 R08: 0000000000000000 R09: 0000000100400027
Jul 12 14:02:17 user kernel: [328873.681610] R10: ffff88001c89ca80 R11: ffff880013b36720 R12: ffff880017b62fa0
Jul 12 14:02:17 user kernel: [328873.681646] R13: ffff8800783f7770 R14: ffff8800783f7780 R15: ffff880017b62fa0
Jul 12 14:02:17 user kernel: [328873.681684] FS: 0000000000000000(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
Jul 12 14:02:17 user kernel: [328873.681724] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 12 14:02:17 user kernel: [328873.681754] CR2: 00007f73ed7f1f48 CR3: 0000000001e0a000 CR4: 0000000000000670
Jul 12 14:02:17 user kernel: [328873.681791] Stack:
Jul 12 14:02:17 user kernel: [328873.681802] ffff880067017bc0 ffffffff811d3139 00005560febbdfff ffff8800783f7708
Jul 12 14:02:17 user kernel: [328873.681845] ffff8800137b33e8 0000556100431000 0000000000000000 ffff880067017c18
Jul 12 14:02:17 user kernel: [328873.681887] ffff8800783f7708 ffff880067017c00 ffffffff811c4a11 0000000000000000
Jul 12 14:02:17 user kernel: [328873.681928] Call Trace:
Jul 12 14:02:17 user kernel: [328873.681946] [] unlink_anon_vmas+0xb9/0x1f0
Jul 12 14:02:17 user kernel: [328873.681977] [] free_pgtables+0xa1/0x120
Jul 12 14:02:17 user kernel: [328873.682006] [] exit_mmap+0xc1/0x170
Jul 12 14:02:17 user kernel: [328873.682035] [] mmput+0x57/0x130
Jul 12 14:02:17 user kernel: [328873.682061] [] do_exit+0x27a/0xb00
Jul 12 14:02:17 user kernel: [328873.682088] [] do_group_exit+0x43/0xb0
Jul 12 14:02:17 user kernel: [328873.682117] [] get_signal+0x294/0x600
Jul 12 14:02:17 user kernel: [328873.682147] [] do_signal+0x37/0x6f0
Jul 12 14:02:17 user kernel: [328873.682175] [] ? __fpu__restore_sig+0x84/0x4a0
Jul 12 14:02:17 user kernel: [328873.682207] [] ? group_send_sig_info+0x35/0x40
Jul 12 14:02:17 user kernel: [328873.682239] [] ? SYSC_kill+0x10f/0x1c0
Jul 12 14:02:17 user kernel: [328873.682268] [] ? dput+0x34/0x230
Jul 12 14:02:17 user kernel: [328873.682295] [] exit_to_usermode_loop+0x8c/0xd0
Jul 12 14:02:17 user kernel: [328873.682327] [] syscall_return_slowpath+0x4e/0x60
Jul 12 14:02:17 user kernel: [328873.682361] [] int_ret_from_sys_call+0x25/0x9f
Jul 12 14:02:17 user kernel: [328873.683525] Code: 48 85 c9 74 0b 48 8b 49 18 48 39 ca 48 0f 42 d1 48 39 50 18 75 aa 4d 85 c0 74 0f 48 c7 c2 20 fe 1b 81 4c 89 c7 e8 04 79 24 00 5b <5d> c3 48 89 c3 e9 3b ff ff ff 48 8b 57 20 49 89 d0 49 83 e0 fc
Jul 12 14:02:17 user kernel: [328873.684017] RIP [] anon_vma_interval_tree_remove+0x18d/0x250
Jul 12 14:02:17 user kernel: [328873.684017] RSP
Jul 12 14:02:17 user kernel: [328873.693035] ---[ end trace cba8ddaf75a598e2 ]---
Jul 12 14:02:17 user kernel: [328873.694137] Fixing recursive fault but reboot is needed!

I don't want to reinstall the system, maybe there is a solution...

Answer 1

The first line of the log shows that the apport process called a segfault; on the next crash see if it will apport again. If there is a problem again because of it, then try to remove the apport package sudo apt remove apport(you can live without this package)
If another process is indicated in the logs next time, then there is a high probability that this is a problem with the hardware. And among iron - first of all suspicion on a RAM. Those. You will need to run a full test of the RAM.

Answer 2

looks like an operative? apport removed