/tmp never cleared

[Meinersbur]

Ubuntu deletes all files in /tmp when booting. Other distributions (eg. RedHat) have a cronjob tmpwatch that deletes these files or even use tmpfs to mount /tmp.

WSL does not 'boot' nor has anacron running. The Windows Disk cleanup program does not consider the files in %USERPROFILE%/AppData/Local/lxss/rootfs/tmp. Hence these are never deleted (automatically).

My suggestion is to clean /tmp when the last lxss process closes. It already terminates background processes when there is no more bash session. At that point no process can access files in /tmp anymore and by Filesystem Hierarchy Standard files cannot be expected to be kept.

[fpqc]

@Meinersbur I wonder if they're going to make it actual in-RAM storage like it is on Linux. If that's the plan, they might not do it this way.

[aseering]

@fpqc FYI -- /tmp is not in-RAM on my Ubuntu 16.04 VM. It's not mounted at all; it's just a directory under /, which is a regular ext4 filesystem.

[S-ed]

It's not only /tmp all the files that You deleting under bash are left on the hdd.
I'm using npm, and it's updating files quite often, my npm folder is clean if you look from bash. But all the files are on hdd if I look in lxss folder.

[fpqc]

@S-ed I believe it does clean them up after you end the Linux Instance (right now this means close all instances of bash.exe)

[S-ed]

@fpqc nope, still there, even after windows reboot.

[fpqc]

@Sed On Drvfs? On Lxfs (outside of /mnt)? Did you touch them with Windows tools?

[S-ed]

@fpqc

C:\Users\S-ed\AppData\Local\lxss\home\s-ed.npm
C:\Users\S-ed\AppData\Local\lxss\root.npm

Did nothing (outside of bash).

Try it Yourself, use:

sudo npm install -g express
sudo npm uninstall -g express

edit: now I've got it ls just not showing me any files/folders started with dot ., faced same thing with .git (fixed with ls -a)

[bitcrazed]

@S-ed please READ THIS - we STRONGLY recommend you do NOT spelunk into the Linux filesystem using Windows apps and tools. https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

[S-ed]

@bitcrazed Yeah. I've kinda learned this lesson last year.
Issue was related to bash was calling windows version of the npm, instead of linux one.
(IIRC now it's fixed)

[therealkenc]

The ask in the original post here was that WSL /tmp is not being scrubbed, but should be, like Real Ubuntu. The OP then went and made the terribly unfortunate mistake of using the words "Windows Disk cleanup" and mentioning win32 paths. All hope was pretty much lost at that point.

On recent versions of Ububtu /tmp is cleaned by tmpreaper, which of course does not run on WSL because no cron. More here.

This is a dupe of #511, or, alternately, a feature request (with the 'init' label) if one subscribes to the idea that WSL init should do some systemd things like #2530.

[S-ed]

@therealkenc Yep. I thought it's caused by the same issue as the /tmp one, but it wasn't.

[Meinersbur]

@therealkenc I think there is more than one way to implement this, Running tmpreaper would be one possibility, but not the only one. Considering that "Windows Disk cleanup" is a Windows component that should be aware of special paths, I don't think its terribly unfortunate. One could install a Disk Cleanup Handler that runs eg. bash -c "rm -rf /tmp/*". However, I would not consider it the best option.

[therealkenc]

Considering that "Windows Disk cleanup" is a Windows component that should be aware of special paths

There, you used the words again. Can't say I didn't try to help you out....

[bitcrazed]

Yeah, no. We won't be relying on WinDiskCleanup to non-deterministically clean tmpfs in WSL - that's something we do when terminating a session.

Just got off a team-sync call where we briefly discussed some of the init challenges and what we might be able to do. Will be meeting post-turkey-coma to discuss in more detail.

[Angeldude]

Has anything come of this?

[bitcrazed]

Hey @ALL. We've certainly discussed it, but we've yet to figure-out a sensible, universal/cross-distro solution that would work for everyone.

• When should we clean tmp?
  • Before we start a new session?
  • After a session closes?
  • Periodically in the background (requires daemon support - coming in spring 2018 udpate)
• How often? On every new session start? Once a day/week/month?
• Should we nuke everything? If not, what filter criteria should we use? Anything older than a week? Month? year?
  • As one of our dev's asks "sorry I know you just downloaded a 10gb file but it's gone now, download it again"

As @Meinersbur points out above: There isn't even much consistency in the Linux distros themselves about when tmp gets cleared:

Ubuntu deletes all files in /tmp when booting. Other distributions (eg. RedHat) have a cronjob tmpwatch that deletes these files or even use tmpfs to mount /tmp.

I think its best we leave decisions about when and how to nuke your tmp folder to the user and/or distro. Though we'd love to hear suggestions from y'all if you think you have a universal solution.

[nesl247]

I didn't realize different distros did it differently. I was always under the impression that everyone wiped it on bootup/shutdown depending on if it was tmpfs or not.

So I'm all for as soon as the Windows session ends, clear /tmp.

[WSLUser]

Periodically in the background (requires daemon support - coming in spring 2018 update

Would that be the systemd daemon we're talking about as mentioned in #2530? If so, how's #1579 and #2533 looking? The latter issue specifically would resolve this issue for Ubuntu (which is still the primarily official distro used). Not sure if the former is a dependency for this particular issue but suspect it is.

Or are we referring to the background task support?

[aseering]

I would advocate that WSL itself ideally shouldn't do this. I think it should be the responsibility of the distro userspace, because that's how it works on regular Linux.

If WSL doesn't yet support whatever mechanism a given distro uses, I would propose tweaking its image to do something equivalent using kernel and init surfaces that WSL does currently surface.

Are there any WSL distro maintainers on this bugtracker these days? Do they have any thoughts about what the best experience is for their users?

I don't personally see a need to rush this. But if there is a need, +1 to "wipe on session termination" as a short-term hack. I think the lack of awareness here that different distros do this differently is an argument that people probably won't care hugely if the behavior changes slightly as WSL becomes able to use distros' built-in /tmp-clearing logic.

[therealkenc]

People who feel strongly about it can start cron in their .bashrc, guarding to check if it is running already. As with sshd, rsyslogd, and whatever their fancy. There is no blocking surface for tmpreaper (or, call me surprised if there is).

I keep meaning to make a run at systemd like I did with Chrome but just never get around to it because like you implied it just isn't that blocking. Well that and because systemd is broken by design and making it work feels like enabling (in the mental health sense).

[S-ed]

@bitcrazed
From my perspective - wiping on exit is good for security reasons.
Even if the WSL session crashed, you could always rerun it and it will be cleaned on exit.

Let users set this setting.
Make it possible for users to enable/disable cleaning, on launch/on exit, periodically/on size limit.
Everyone is different, there are no solution that would fit all the users.
Also, agree with @aseering on making this by the distro means, if this possible.

[WSLUser]

Also, agree with @aseering on making this by the distro means, if this possible.

I also agree that WSL should support whatever distros require for their mechanisms to work to clear /tmp. From a security perspective (as well as a storage perspective), I'd always like to see this data auto-removed and leave a nice little log entry that you could look at if you really wanted confirming the auto-removal worked.

[avatar21]

I had exactly the same issue with my Windows ... but is it created by WLS ? Or something else ?？
Because I don't remember I had those dir in my linux systems, I had 3 copies of them and non have similar file dir
C:\Users\<username>\AppData\Local\lxss\home\<username>\tmp\npm-<some-random-text>

[WSLUser]

It's part of the userspace that's pulled down with the image. Just open WSL, cd / and ls. You'll see a /tmp just as you observed from discovering the Windows path. Just rm -rf it for now or create a script to do that for you.

[rigarash]

I agree that this is the distro policy whether cleaning /tmp on boot or not.
But in order to change this feature from WSL side, how about add config setting in /etc/wsl.conf ?

[therealkenc]

config setting in /etc/wsl.conf ?

Absolutely.

It should be made as general as possible though, to address Rich's tough questions. It should probably be able to run arbitrary scripts, be it tmpreaper or tmpwatch (which are the same thing forked over a spat nearly 20 years ago), or any other script for that matter. Maybe there could be some kind of flexible syntax in /etc/wsl.conf for scheduling when the scripts are run. Users should probably be able to set the year, the month of the year, day of the week, hour, minute. Perhaps there could be some kind of special character, asterisk maybe, to indicating running the script every week/day/hour/etc instead of a specified one. There could also be a different character, question mark maybe, to indicate running it only at startup.

Something like that.

[therealkenc]

Since #344 was deemed addressed, following suit.

[AgDude]

@therealkenc #344 did not address this issue on ubuntu, the /tmp directory still grows indefinitely on a default ubuntu wsl instance.

[bobhy]

Here is my interim workaround:
Define a task in Windows Task Scheduler that runs the following command when my user logs in:

c:\windows\system32\wsl.exe --user root --distribution ubuntu /etc/init-wsl

(you know where this is going...)
In distribution ubuntu, create a file /etc/init-wsl:

tmpreaper 96 /tmp

(my own version of this file also starts dbus, avahi-daemon and xrdp so I have a stable DNS name to connect to....)

[igoradamenko]

Hey there.

I've run into the same problem — the /tmp directory is not cleared. I'm using Ubuntu 20.04. If I'm right, the distro should automatically clear /tmp on boot due to the policies described in /usr/lib/tmpfiles.d/tmp.conf (see man tmpfiles.d), which are probably copied from systemd's sources due to its installation process.

But suddenly my /usr/lib/tmpfiles.d/tmp.conf looks like this:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# Clear tmp directories separately, to make them easier to override
D /tmp 1777 root root -
#q /var/tmp 1777 root root 30d

- in the first rule means “never”, the second line is even better — it's commented. So, this file actually defines the current behavior, and this is probably the reason why my /tmp is never cleared.

I'm sure that I didn't touch this file by myself. However it looks very strange.

So, I'm here to ask those of you who encounter the same problem on Ubuntu 18.04 or newer. Would you mind to check your /usr/lib/tmpfiles.d/tmp.conf? Does it look like the one from systemd's repo or like mine?

[igoradamenko]

Ah, nevermind.

It looks like systemd-tmpfiles (which should analyze the config I posted above) is not fired up during the boot. Probably because it should be started by systemd, but according to #994 systemd does not work :-(

As an alternative, I guess, it should be possible to run this command on cron, or use tmpreaper.

But for some reason systemd-tmpfiles does not clean all the files inside /tmp, so I'm not sure that it should be used 😞

[aradalvand]

Sorry, why was this issue closed? I'm not really sure the problem is solved here...

[rfc2119]

I second this. /tmp is not cleaned on Ubuntu 22.04

[darkvertex]

FYI if you enable the new systemd support in WSL2, afterwards you can enable tmp.mount to get a proper tmpfs /tmp mount when WSL initializes, like so:
sudo systemctl enable /usr/share/systemd/tmp.mount

After the above and restarting WSL, you can check if it worked via mount | grep /tmp and you should see a line like tmpfs on /tmp type tmpfs (rw,nosuid,nodev).

You can obviously confirm further by "touching" a file (ie touch /tmp/potato) then exit WSL (wsl --shutdown) and then go back in a wsl shell and the file should be gone (ie ls /tmp/potato should fail.)

---

Knowledge credit: #6999 (comment)

[rgmz]

FYI if you enable the new systemd support in WSL2, afterwards you can enable tmp.mount to get a proper tmpfs /tmp mount when WSL initializes, like so:
sudo systemctl enable /usr/share/systemd/tmp.mount

One potential caveat: doing this replaces your /tmp mount, it doesn't clear data in your existing (old) mount.

In my case, I had to disable /usr/share/systemd/tmp.mount, purge the old data, then re-enable it.

# old
$ du -sh /mnt/wslg/distro/tmp/
515G    /mnt/wslg/distro/tmp/

# new
$ du -sh /tmp/ 2>/dev/null
185M    /tmp/