18

I have a small server which I use for testing and programming. Currently it runs Debian 9.4 stretch with 4.14.0-0.bpo.3-amd64 kernel.

Today I tried to connect through SSH but I couldn't then I tried to ping it and it was unreachable. Therefore I had to hard-restart it by unplugging power cable. Then I went to /var/log/syslog and I found a strange line containing exactly 6140 characters like the following

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

then nothing else until new log entries of system restart. This is actually the first time it happens.

Does someone know what could it be?

GAD3R
  • 66,769
DrKey
  • 291
  • 2
    Well I wrote about this at https://askubuntu.com/a/1020373/43344 , for one. (-: Then there are https://unix.stackexchange.com/questions/227173/ and https://unix.stackexchange.com/questions/237321/ … – JdeBP Oct 24 '18 at 14:32
  • 1
    @JdeBP I prefer your first answer/link, that is indeed it. Odd has a question with 1500+ visits you have not got a single vote, +1. – Rui F Ribeiro Oct 24 '18 at 15:01

2 Answers2

20

That syslog file content you are showing us of all zeros is indeed corruption of the filesystem/syslog writing.

Your system crash caught the system mid-writing to the syslog file, and that is the end result.

Already have seen it happening several times over the years, in Linux VMs and a couple more times in Raspberries and Banana Pis.

Nothing to obsess (too much) about or lose a lot of time to investigate why you have this for a one-time event. I would be more worried at finding out why it crashed, especially if it is a regular event.

PS getting into anecdotal territory, last time I had this happening regularly in a Banana Pi R1, I managed to trace the cause to a (faulty) realtek wifi chipset.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
  • 6
    It's also worth noting that ^@ is the NUL byte (byte value 0), so it's "empty" data that is appended to the log file by accident. This could happen, for example, when a new empty block is assigned to the end of the file, but the amount of bytes actually occupied by meaningful data in that block is not updated properly (because the crash / hard reset occurred before that counter was committed to the drive). – marcelm Oct 24 '18 at 19:01
  • how to find out why it crashed? – Nusrat Nuriyev Jul 03 '19 at 15:44
  • @CEOatApartico I would advise opening a new question. – Rui F Ribeiro Jul 03 '19 at 16:02
  • @RuiFRibeiro https://unix.stackexchange.com/questions/528275/how-to-find-why-the-system-is-crashed – Nusrat Nuriyev Jul 03 '19 at 21:25
9

To slightly expand on that answer, your syslog have the content of a page of memory partially committed to disk, with the metadata of syslog not up to date. That string of ^@ chars are actually NUL bytes; exactly what a freshly allocated page of memory initially contains.

Jarhmander
  • 191
  • 1
    A friendly reminder: If you are going base it in JdeBP answer, try to get it right. Disk sectors are zeroed out when allocated by the kernel for security reasons, it is not memory with 0s being written per se. I advise correcting that. – Rui F Ribeiro Oct 24 '18 at 21:49