XDG_RUNTIME_DIR: Periodic clean-up

[Thomas Kluyver]

Me again :-)

XDG_RUNTIME_DIR has a number of useful guarantees, and I want to use it, but I'm finding it tricky to do so in a reliable way.

I've complained before about the fact that processes running in screen/nohup can have the directory deleted from underneath them when the user disconnects. Today my issue is with periodic cleanup. Here's what the spec says:

> Files in this directory MAY be subjected to periodic clean-up. To ensure that your files are not removed, they should have their access time timestamp modified at least once every 6 hours of monotonic time or the 'sticky' bit should be set on the file. 

This is awkward for application developers firstly because it's so easy to overlook: either you've discovered XDG_RUNTIME_DIR without reading the spec, or you saw the note in the spec but skipped it 'for the time being' because it's rare to need the files 6 hours later. Of course, 'for the time being' can easily mean 'until someone has filed a strange bug and we've figured out what's caused it'.

If you have got to the point of knowing & caring about it, it's still frustrating, because:

- How do you test for this? Our automated tests can't wait 6 hours. It's a pain even for a one off manual test.
- Does my system do the periodic cleanup? It's not required - maybe my setup doesn't do it, or does it only after 24 hours, or only when a certain amount of space is used.
- How do I even find out? Is it Gnome that would do it? Systemd? Pam? A separate service? I'm sure this is obvious to someone better versed in the components of a modern Linux system, but it's not obvious to me, and I'd wager that there are plenty of other people who wouldn't know.
- How does the access time/sticky bit check work if I make a subdirectory? Does it only apply to the first level under XDG_RUNTIME_DIR, or only to leaf files, or to every file and directory working recursively?
- If I try to set the sticky bit and a file is deleted anyway, how do I check whether it was my code that failed or whatever system component is doing the cleanup? I can't retrospectively check the sticky bit, because the file is gone!

Finally, if you do find something that works to protect you from the cleanup, you'll probably cargo cult it for every file you create in XDG_RUNTIME_DIR. That's certainly what I'd do. So there will gradually be more and more files that aren't being cleaned up, defeating the point of cleanups.

This cleanup feels like an awkward mechanism that pushes a lot of unnecessary work onto application developers - or leaves us with rare but real bugs if we ignore it. I guess the intent is to reclaim unused space, since the directory can be purely in RAM? But 6 hours is plenty of time for a misbehaving application to fill up RAM, even if it hasn't protected its files from cleanup.

Ideally, I'd like to see periodic cleanup phased out, to make the default behaviour less surprising. Maybe there could be a way to opt *in* to periodic cleanup instead of opting out? But if that's not possible, I'd like to at least clarify how the protection rules work with subdirectories, and maybe have some official XDG tooling to facilitate testing this.

Thanks,
Thomas