Moving anything in /var
to a tmpfs is a bad idea at this point, because neither Ubuntu nor any other major Linux distribution support it at the moment. It also has the disadvantage to occupy main memory and to lose all previous log files, which hampers problem diagnosis. SSD drives really aren't that delicate when it comes to write cycles and a few log files don't result in enough data and write operations to reduce the life span of an SSD significantly. Very few SSDs fail because of write cycle exhaustion.
I suspect that /var/log/syslog
still exists, but only on the root file system, because rsyslog
starts before /var/log
is mounted. When you mount another file system at /var/log
, its previous content is hidden underneath.
As a workaround you can bind your root file system somewhere else, which would allow you to inspect its content unshadowed by other mountpoints:
sudo mkdir -p /mnt/root
sudo mount --bind / /mnt/root
You should now see other content in /mnt/root/var/log
.
P.S.: If you have an internal hard disk drive in your machine in addition to an SSD, you can mount /var
from there. That's what I and many other people do and not mainly because of concerns about write cycles. The main reason was always, that a faulty program may accidentally write heaps of (log) data to /var
and nobody would notice until the file system was full, at which point it would be difficult to alleviate the situation, if /var
was part of /
.