Quieting drive activity

Hardware:

  • HP 17-cp1035cl laptop
  • AMD Ryzen™ 5 5625U (6-Core) Processor (lowest 400 MHz, base 2300 MHz, boost 4300 MHz, 12 threads via SMT)
  • 64GB DDR4-3200MHz RAM
  • 500 GB 7200 RPM 128 MB cache internal drive
  • Two 500 GB 7200 RPM 128 cache external drives
  • ZFS file system with the bpool and rpool mirrored on those three drives above

I noticed that every few seconds, my drive lights would flash, and the drives never spun down even when the computer was sitting idle.

Investigating, I found that Linux creates, rotates and destroys a lot of logs on a continual basis.

So:


systemd-journald.service

This can be triggered from:

  • systemd-journald-dev-log.socket
  • systemd-journald-audit.socket
  • systemd-journald.socket

So to completely disable logging:

sudo systemctl status systemd-journald-dev-log.socket
sudo systemctl stop systemd-journald-dev-log.socket
sudo systemctl disable systemd-journald-dev-log.socket
sudo systemctl mask systemd-journald-dev-log.socket
sudo systemctl status systemd-journald-audit.socket
sudo systemctl stop systemd-journald-audit.socket
sudo systemctl disable systemd-journald-audit.socket
sudo systemctl mask systemd-journald-audit.socket
sudo systemctl status systemd-journald.socket
sudo systemctl stop systemd-journald.socket
sudo systemctl disable systemd-journald.socket
sudo systemctl mask systemd-journald.socket
sudo systemctl status systemd-journald.service
sudo systemctl stop systemd-journald.service
sudo systemctl disable systemd-journald.service
sudo systemctl mask systemd-journald.service

systemd-journal-flush.service

sudo systemctl status systemd-journal-flush.service
sudo systemctl stop systemd-journal-flush.service
sudo systemctl disable systemd-journal-flush.service
sudo systemctl mask systemd-journal-flush.service

I know, I know... "You need logs!"... not really until something goes wrong, and I can re-enable them at that time. If the problem is such that I cannot re-enable logs because the machine won't boot, it'll probably necessitate a reinstall anyway.

Anyway, now the drives aren't flashing all the time when the machine isn't being used, and they've even spun down a couple times!

That's not such a big deal for spinning-rust drives, but for SSD drives, quieting the constant dribble of drive writes lengthens drive life by reducing write-wearing.

Another thing I did was to disable the time-based snapshots taken by ZFS... now a snapshot is only taken when the configuration changes (ie: an update is installed, or an application is installed or removed)... I've actually had the machine take so many snapshots in the past that it ran out of drive space on bpool (while it creates snapshots, there's no utility to automatically destroy them). That did a lot to quiet drive activity, too.



[EDIT]
The boot logs are still being kept, but that's not a problem. I can access them via dmesg.

Now that I've disabled systemd-journald.service so logs aren't kept after boot, I can get a glimpse at the amount of logging being done... it's a lot.

In dmesg, there are entries like this:
accounts-daemon.service: Failed to connect stdout to the journal socket, ignoring: No such file or directory

Parsing through all of them, here's what's logging (basically everything that starts up, in alphabetical order below):

accounts-daemon.service
alsa-restore.service
anacron.service
apparmor.service
binfmt-support.service
bluetooth.service
boot-efi.mount
boot-grub.mount
boot.mount
colord.service
console-setup.service
cpufrequtils.service
cron.service
dbus.service
dev-disk-by\x2duuid-c39fbec2\x2d4aa6\x2d4255\x2db6c3\x2de9540b397713.swap
dev-disk-by\x2duuid-d4398e10\x2d8183\x2d4a5a\x2d88a6\x2d9d830a6f2a6d.swap
dev-disk-by\x2duuid-f51c1888\x2dc76e\x2d4f16\x2db25e\x2d2ba99b697696.swap
dev-hugepages.mount
dev-mqueue.mount
e2scrub_reap.service
fwupd.service
gdm.service
grub-common.service
grub-initrd-fallback.service
home-owner.mount
irqbalance.service
keyboard-setup.service
kmod-static-nodes.service
lm-sensors.service
loadcpufreq.service
mnt-01ED\x2dFF42.mount
mnt-1B0B\x2d0AE5.mount
mnt-OldRB.mount
mnt-Storage1.mount
mnt-Storage2.mount
mnt-Ventoy.mount
mnt-VTOYEFI.mount
ModemManager.service
modprobe@efi_pstore.service
modprobe@pstore_blk.service
modprobe@pstore_zone.service
modprobe@ramoops.service
networkd-dispatcher.service
NetworkManager-dispatcher.service
NetworkManager.service
ondemand.service
packagekit.service
plymouth-quit-wait.service
plymouth-read-write.service
polkit.service
proc-sys-fs-binfmt_misc.mount
root.mount
rtirq.service
rtkit-daemon.service
setvtrgb.service
srv.mount
sys-fs-fuse-connections.mount
sys-kernel-config.mount
sys-kernel-debug.mount
sys-kernel-tracing.mount
systemd-backlight@backlight
systemd-modules-load.service
systemd-random-seed.service
systemd-remount-fs.service
systemd-rfkill.service
systemd-sysctl.service
systemd-sysusers.service
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-setup.service
systemd-udev-settle.service
systemd-udev-trigger.service
systemd-udevd.service
systemd-update-utmp-runlevel.service
systemd-update-utmp.service
systemd-user-sessions.service
thermald.service
udisks2.service
ufw.service
unattended-upgrades.service
upower.service
user-runtime-dir@1000.service
user@1000.service
usr-local.mount
var-games.mount
var-lib-AccountsService.mount
var-lib-apt.mount
var-lib-dpkg.mount
var-lib-NetworkManager.mount
var-lib.mount
var-log.mount
var-mail.mount
var-snap.mount
var-spool.mount
var-www.mount
wpa_supplicant.service
zfs-import-scan.service
zfs-load-module.service
zfs-mount.service
zfs-share.service
zfs-share.service
zfs-volume-wait.service
zfs-zed.service
zsys-commit.service
zsysd.service
4 Likes

It would be interesting to see which ones of these services generate the most logs, and disable them individually as opposed to disable all logging activity.

Looking a bit into this, it seems there's also the possibility of enabling in-memory only logs so that disk is never written to but the information is still available during that session. I'm not sure how this works but I'm curious about it so I'll dig more into it.

EDIT:

I looks like it may be as simple as editing /etc/systemd/journald.conf and set the Storage option to either "volatile" or "none".

Storage=
Controls where to store journal data. One of "volatile", "persistent", "auto" and "none".

If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed).

If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable.

"auto" behaves like "persistent" if the /var/log/journal directory exists, and "volatile" otherwise (the existence of the directory controls the storage mode).

"none" turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work).

Defaults to "auto" in the default journal namespace, and "persistent" in all others.

Some interesting thread on the subject: raspbian - How to disable logs? - Raspberry Pi Stack Exchange

1 Like

I had Storage=volatile set, but it still rotated the logs to persistent storage... so while the current set of logs isn't stored on-disk, that set of logs will be rotated to on-disk after a time. I've found no way of turning that off.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.