Storage space fills up really quickly when using Plasma (and only Plasma)

For some reason, for at least three months now, whenever I use Plasma as my desktop, my disk gets filled up really, really quickly, and this keeps happening even after I delete or move stuff from the partition (I once deleted a 2 gig git repo that I didn’t need anymore, but then my partition filled straight back up to literally 0 bytes free after only around 30 minutes. That’s how fast it goes.) From what I’ve seen, this only happens when using Plasma as a desktop environment; if I use something else, like LXQt or awesome, this doesn’t happen for some reason (or it could be happening really slowly?), so it has to be a problem with my installation of Plasma or some service running alongside it that does some really intense logging or something. As of right now, I have to use something other than Plasma when using that installation of openSUSE, because the partition gets filled up so quickly to such a point that the operating system is literally unusable. I don’t know exactly what kind of information would be helpful here, so ask me questions if you need any more information.

@blobchapeau something coredumping or hammering the journal logs… If you tail the logs is it busy (need to be root user)?

coredumpctl
journalctl -f

I’m running TW Plasma on four machines, no space issues.

Have you performed a ‘vacuum’ of the systemctl log files?

Are you using snapshots? If yes, have you done a ‘snapper list’ to see how much space they’re taking?

Have you done a

btrfs filesystem usage -T /

??

Have you used any sort of space sniffer tool to see where the excessive use is?
(many offer a graphical pie chart to visually show usage, while navigating the file system)

I was going to recommend a sniffer program too … I use FileLight (under System menu, if installed)

samrpf:/home/samr # coredumpctl
TIME                         PID  UID  GID SIG     COREFILE EXE                SIZE
Tue 2023-12-05 15:23:27 PST 4494 1000 1000 SIGSEGV missing  /usr/local/bin/edi    -
Tue 2023-12-05 15:24:01 PST 4742 1000 1000 SIGSEGV missing  /usr/local/bin/edi    -
Tue 2023-12-05 15:24:13 PST 4854 1000 1000 SIGSEGV missing  /usr/local/bin/edi    -
samrpf:/home/samr # journalctl -f
Dec 05 19:29:03 samrpf.lan pipewire-pulse[2754]: mod.protocol-pulse: client 0x55961aee8a40 [terminology]: ERROR command:-1 (invalid) tag:20 error:25 (Input/output error)
Dec 05 19:29:03 samrpf.lan pipewire-pulse[2754]: mod.protocol-pulse: client 0x55961aee8a40 [terminology]: ERROR command:-1 (invalid) tag:21 error:25 (Input/output error)
Dec 05 19:29:46 samrpf.lan su[2891]: gkr-pam: stashed password to try later in open session
Dec 05 19:29:46 samrpf.lan su[2891]: pam_kwallet5(su:auth): pam_kwallet5: pam_sm_authenticate
Dec 05 19:29:46 samrpf.lan su[2891]: pam_kwallet5(su:auth): pam_kwallet5: we were already executed
Dec 05 19:29:46 samrpf.lan su[2891]: (to root) samr on pts/0
Dec 05 19:29:46 samrpf.lan su[2891]: pam_kwallet5(su:setcred): pam_kwallet5: pam_sm_setcred
Dec 05 19:29:46 samrpf.lan su[2891]: pam_unix(su:session): session opened for user root(uid=0) by samr(uid=1000)
Dec 05 19:29:46 samrpf.lan su[2891]: pam_kwallet5(su:session): pam_kwallet5: pam_sm_open_session
Dec 05 19:29:46 samrpf.lan su[2891]: pam_kwallet5(su:session): pam_kwallet5: we were already executed

journalctl didn’t stop running. I’m not sure if this is normal or not.

@blobchapeau So it continuously runs the pam_kwallet5 parts, over and over?