3

I am getting random server shutdowns and logs containing unusual values with ^@^@^@^@^@^@^@^@.

This might be related to kernel panic but I don't know or just can't debug it.

Currently, I don't know how to debug this or what to search for as it seems like that the server just freezes.

  • Extract from kern.log

    Jul 19 16:40:38 s158375 kernel: [7224668.279388] [UFW BLOCK] IN=eno1 OUT= MAC=70:54:d2:ab:be:27:00:12:f2:c1:0d:00:08:00 SRC=94.102.51.95 DST=69.30.205.26 LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=55583 PROTO=TCP SP T=44829 DPT=39987 WINDOW=1024 RES=0x00 SYN URGP=0
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Jul 20 02:23:55 s158375 kernel: [    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17
Jul 20 02:23:55 s158375 kernel: [    0.000000] Linux version 4.15.0-76-generic (buildd@lcy01-amd64-029) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 (Ubuntu 4.15.0-76.86-generic 4.15.18)

  • Extract from syslog

    Jul 19 16:40:38 s158375 kernel: [7224668.279388] [UFW BLOCK] IN=eno1 OUT= MAC=70:54:d2:ab:be:27:00:12:f2:c1:0d:00:08:00 SRC=94.102.51.95 DST=69.30.205.26 LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=55583 PROTO=TCP SPT=44829 DPT=39987 WINDOW=1024 RES=0x00 SYN URGP=0
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@Jul 20 02:23:55 s158375 keyboard-setup.sh[288]: cannot open file /run/tmpkbd.EXiK19
Jul 20 02:23:55 s158375 kernel: [    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17
Jul 20 02:23:55 s158375 systemd[1]: Mounted Kernel Debug File System.
AdminBee
  • 22,803
Krasimir Iliev Velichkov
  • 31
  • 2
    This is in part https://unix.stackexchange.com/q/477537/5132 again. – JdeBP Jul 20 '20 at 09:17
  • 1
    I smell a memory/disk corruption of some sort. Run memtest86 https://www.memtest86.com/download.htm and check dmesg for disk errors. – Artem S. Tashkinov Jul 20 '20 at 09:29
  • Thanks, this is the info that I needed. Surely it's the hardware because this is a very cheap rental server(or the constant high load of data processing). – Krasimir Iliev Velichkov Jul 20 '20 at 10:39
  • A block of disk space was allocated for appending more data to the end of the log file, and then after the allocation was done but before the actual data could be transferred to the disk, the system crashed. ^@ is a representation of the NUL byte, or ASCII 0x00. If the server has a management processor, check its hardware error log with ipmitool sel list or a vendor-specific tool. Check for power faults: this could be as simple as server suddenly losing power completely for any reason. – telcoM Jul 20 '20 at 11:18

0 Answers0