Checking here, I have only 5 such directories. And the newest has a date of Jul 14.
Checking on another system, I notice 40 directories. On that system, I am allowing the desktop updater to run. On my main desktop (using KDE), I disabled that in tray settings.
I guess the update applet is responsible for many of those directories.
henk@boven:~> ls -l /var/tmp
total 116
drwx------ 5 henk users 4096 Jun 18 14:36 kdecache-henk
drwx------ 2 kdm kdm 4096 Mar 17 2017 kdecache-kdm
drwx------ 2 marian wij 4096 Jan 22 2020 kdecache-marian
drwx------ 2 marian users 4096 Apr 15 2017 kdecache-test
drwx------ 2 mysql mysql 4096 Dec 21 2018 mysql-protected.1AYbRU
drwx------ 2 mysql mysql 4096 Dec 2 2018 mysql-protected.21TlOp
drwx------ 2 mysql mysql 4096 Oct 19 2018 mysql-protected.Cqb5th
drwx------ 2 mysql mysql 4096 Nov 3 2018 mysql-protected.PYCAVU
drwx------ 2 mysql mysql 4096 Nov 25 2018 mysql-protected.Qfm3bU
drwx------ 2 mysql mysql 4096 Dec 22 2018 mysql-protected.SDKcnz
drwx------ 2 mysql mysql 4096 Dec 25 2018 mysql-protected.T0K5yG
drwx------ 2 mysql mysql 4096 Dec 21 2018 mysql-protected.UvriYB
drwx------ 2 mysql mysql 4096 Oct 19 2018 mysql-protected.Wz3MmX
drwx------ 2 mysql mysql 4096 Dec 26 2018 mysql-protected.ddChvf
drwx------ 2 mysql mysql 4096 Oct 19 2018 mysql-protected.fRsXtT
drwx------ 2 mysql mysql 4096 Nov 3 2018 mysql-protected.lL4nsj
drwx------ 2 mysql mysql 4096 Dec 8 2018 mysql-protected.le6lNn
drwx------ 2 mysql mysql 4096 Nov 25 2018 mysql-protected.w1BD7f
drwx------ 3 root root 4096 Aug 14 09:47 systemd-private-c2fa9be939df4d37a8ba7c8d116498fb-apache2.service-edHji2
drwx------ 3 root root 4096 Aug 14 09:47 systemd-private-c2fa9be939df4d37a8ba7c8d116498fb-ntpd.service-WMofYZ
drwx------ 3 root root 4096 Aug 14 09:47 systemd-private-c2fa9be939df4d37a8ba7c8d116498fb-rtkit-daemon.service-mmvwtA
drwx------ 5 root root 4096 Jan 31 2018 zypp.RvH04k
drwx------ 5 root root 4096 Dec 29 2017 zypp.XNGgyi
drwx------ 5 root root 4096 Dec 27 2017 zypp.dLOJFn
drwx------ 5 root root 4096 Dec 27 2017 zypp.kBTtAy
drwx------ 5 root root 4096 Dec 30 2017 zypp.nZDYgD
drwx------ 5 root root 4096 Jan 31 2018 zypp.oTEk2h
drwx------ 5 root root 4096 Jan 7 2018 zypp.sJeHkn
drwx------ 5 root root 4096 Dec 30 2017 zypp.uzg1Ai
henk@boven:~>
I think you were right earlier, when you suggested that it is packagekit.
I have very few, because I disable the desktop update applet in KDE. So packagekit does not normally run.
I occasionally login to Gnome, and I have not found a way of disabling the update applet there. So the few entries that I see may be due to the Gnome update applet. Or maybe running some other update software occasionally leaves something. But the most recent directory for me is 1 month old, so most of what I do is not creating those directories.
On another Leap 15.2 system (this one a virtual machine), there are recent directories. I never use packagekit to update. But the update applet is enabled so that it can report when there are updates. And the most recent directory has today’s date, so just checking for updates (with the desktop applet) seems to have created a directory.
from the command line. And that did create a new "/var/tmp/zypp.* directory.
That’s another pointer to packagekit being the problem.
I think it happens because packagekit keeps its own copy of metadata, instead of merging that into the data cached by “zypper”. Perhaps it does this to avoid lock conflicts.
However, if you disable packagekit, then you won’t be able to use Gnome software.
That would be fine for me, because I don’t use it. But it would be nice to just disable the update applet without removing the ability to use Gnome software. For example, in KDE I am able to disable the update applet, but still use Discover if I want to use that (which I don’t, but some people do).
cd /etc/tmpfiles.d
cp /usr/lib/tmpfiles.d/tmp.conf .
I then edited “tmp.conf” and modified the line for “/var/tmp”. I changed the “-” at the end of that line to “14d”. I think it is now supposed to delete anything older than 14 days. I’m not sure if it does anything until next boot, or until I restart the service.
I will see what happens.
I did not change the line for “/tmp” because that is using “tmpfs” here, so is emptied at every boot.
That would be fine for me, because I don’t use it. But it would be nice to just disable the update applet without removing the ability to use Gnome software.
The notifier can be disabled via Settings > Package Updater > Notifications (turn off), and if you launch the ‘Package Updater’, there is an option to remove it, although I haven’t invoked that.
I have a single directory named “zypp.xxxxxx”, and from what I could gather, it’s from a day zypper never exited. There’s many subsequent messages about other zypper processes being locked out by the first one, which kept quiet until shutdown (timestamp of shutdown coincides with modify timestamp). The content is related to KeyRing, so gpg keys stuff. Not really a bug in my case, but in your case it could be the process is being killed.
Well, over time, it struck me that many people say things like this (this happens on reboot) where in fact it happens on shutdown and the effect will be noted on next boot (not only on re-boot).
One can of course take it for granted that most of these people in fact know how it is in reality, but I am afraid that a number of people do not understand the way these things happen and will not learn anything from this faulty way of explaining.
