recently, I have found I have tmpfs mounted on /run/user/$UID I really don't know where this comes from, and I don't want it on Fedora, I know this comes from systemd land ... but I don't use systemd on Gentoo and I cannot find any news item about this new nonsense, nor any useful docs, relevant to Gentoo
Well, this is not a systemd specific behavior I suppose. On my systems without systemd I have the same mounts. Any chance you either have sys-auth/consolekit or sys-auth/elogind installed and running?
yes, I have sys-auth/consolekit-1.2.0 as part of dependency chain of some KDE stuff I've just went through configfiles it install into /etc, i.e. /etc/ConsoleKit/seats.d/00-primary.seat /etc/X11/xinit/xinitrc.d/90-consolekit -- aw, that's a script, not config /etc/dbus-1/system.d/ConsoleKit.conf and I don't see anything that would even remotely resemble any option to control that mount
$XDG_RUNTIME_DIR is a freedesktop / XDG spec, its not a systemd thing. the spec says it should be a tmpfs and cleared out at reboot or logout. in your case consolekit is creating it when you login. why do you not want it? tmpfs doesnt take up any ram if the mount is empty and most desktop environments rely on it since its much more secure than putting random files in /tmp where any user can read them.
(In reply to Jason Zaman from comment #3) > $XDG_RUNTIME_DIR is a freedesktop / XDG spec, its not a systemd thing. thankyou for the pointer the discussion was where the actual mountpoint comes from, not about freedesktop specs, but lets see them anyways: > the spec says it should be a tmpfs and cleared out at reboot or logout. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html - hm, where exactly does that mention 'tmpfs'? > in your case consolekit is creating it when you login. I don't want this and I don't want this to be default (see below) > why do you not want it? tmpfs doesnt take up any ram if the mount is empty yeah, and the sun shines if it shines, right? :-) so, if it doesn't take any RAM, because it is empty, then why anything empty should even exist on my system? or isn't it rather that it [usually] isn't empty and so it *takes* RAM? hm, thinking about it a bit more, doesn't tmpfs take some RAM (and other system resources) just by its existence? let's say I'll create about 64 k empty tmpfs mounts ... the kernel memory usage won't increase a single byte? # free total used free shared buff/cache available Mem: 1882408 82700 1526344 8720 273364 1623232 Swap: 0 0 0 # for i in $(seq 1 64000) ; do mkdir $i ; mount -t tmpfs none $i ; done mount: mount none on /root/tmpfstest/49981 failed: No space left on device ... mount: mount none on /root/tmpfstest/64000 failed: No space left on device oh, it has eaten so much resources that I cannot even finish this stupid experiment? now let's see if it is empty on my system ... $ du -hs /run/user/1000 476K /run/user/1000 hm, not that much ... but the biggest file is a logfile, and it keeps growing; the app is running for just three hours and it already produced ~400 KB, and it's mostly idling ... I wonder how it will look like after a week, with some activity - oh, now I see why the app might get stuck from time to time, it runs out of space and it is 'badly written', not being able to cope with sudden inability to write to an open file? (just a wild guess :-)) hmpf, do I really need that logfile, which I almost never read, to be kept in memory? > and most desktop environments rely on it really? well, obviously, I'm not expert in these matters, but I seriously doubt that any DE does check whether $XDG_RUNTIME_DIR is tmpfs mount and refuse to run otherwise ... > since its much more secure than > putting random files in /tmp where any user can read them. how is putting random files into user-only readable/writable directory under /tmp less secure than putting them into user-only readable/writable directory anywhere else? do permissions/selinux/whatever work different under /tmp than under /run/user? or are you mixing apples and oranges? BTW, before I've finished this, in one of my open consoles I got this message: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-kavol' ... ok, let's see: $ ls -ld /tmp/runtime-kavol drwx------ 2 kavol kavol 4096 5. bře 15.35 /tmp/runtime-kavol $ ls -ld /run/user/1000 drwx------ 4 kavol root 80 21. úno 20.13 /run/user/1000 sooo ... how exactly is the first less secure than the second? p.s. sorry for not being exactly nice ... nothing in person, I just hate those arguments "oh, it's nothing, who cares about two gigs of memory on four gigabytes system ..." - yes, that machine is short on memory and I *do* care
(In reply to kavol from comment #4) > (In reply to Jason Zaman from comment #3) > > the spec says it should be a tmpfs and cleared out at reboot or logout. > > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > > - hm, where exactly does that mention 'tmpfs'? ah, I see that now: "If $XDG_RUNTIME_DIR ... since it might reside in runtime memory and cannot necessarily be swapped out to disk." I'm no native speaker, but I'd say there is quite a difference between "should" and "might" and while at it: "Applications ... should not place larger files in it" - now we might argue that it's not a good idea to log into this directory, so the application doing this, as mentioned in previous comment, is broken, however reading the spec[*], I don't see any other $XDG_* directory that would match (be better for) the usecase [*] and also while at it ... I don't see why the whole world should follow Poettering's squad inventions, freedesktop.org is not any open standards body like IETF for example, with open process where different needs meet, it is merely documenting what the authors decided to implement in systemd and GNOME lands guys, once again, sorry for the tone ... but try to imagine being in my shoes - I have just found a thing that has quite negative impact on my system, I had no clue where it comes from, it just sneaked in without my consent, after finding the culprit I see I can do nothing about that because the package is a hard dependency and there doesn't seem to be any relevant configuration option, and all I am told is that it takes no RAM (yes it eats *my precious RAM*!) and some vague statement about security which _looks_ either red herring or plain false to me :-(
We are not going to start randomly patching packages just because someone 'does not want' something. Since you know the source now, please take it upstream and convince them to support your use case. Alternatively, use user patches to patch it out and live happily ever after. That is, until things start randomly exploding because your system is non-compliant to XDG specs. In which case you should know it's your fault and please do not report bugs about that.
@Michał It's the apps that are not complying to XDG, not his system after applying user patches to apps to not store garbage under XDG_RUNTIME_DIR. @Reporter Michał may sound a bit rude here, but your case really can be best resolved upstream. Please identify those offenders via lsof and report relevant bugs to their upstreams. In my case, /run/user/1000 contains merely pipes, fifos, .pid and other special files you would normally expect from /run: maciek@liwardyna ~ $ du -hs /run/user/1000 8,0K /run/user/1000 If some app doesn't adhere to XDG_RUNTIME_DIR usage guidelines: {quote} If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message. Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk. {quote} it's well worth reporting upstream. In your specific case, apart from getting it fixed upstream, safer will be probably overriding XDG_RUNTIME_DIR env variable to whatever suitable location that meets XDG volatility requirements.
(In reply to kavol from comment #4) > (In reply to Jason Zaman from comment #3) > > in your case consolekit is creating it when you login. > I don't want this > and I don't want this to be default (see below) in that case you can just disable the consolekit useflag and remove it completely?
