Mageia forum

I just noticed that Mageia 3 is mounting /tmp in RAM. I don't want it to do this; I want it where I want it, which is on a hard drive.

Where is that mount taking place? There is no entry in fstab. I'm sure I could find it, but I'm also sure I would have to hunt for it.

Normally, as i've seen your other posts, wouldn't ask this, but:

Are you sure? Also out of curiosity, please show

Code: Select all

mount | grep tmp
grep tmp /etc/fstab
systemctl status tmp.mount
systemctl show tmp.mount

By default, /tmp is not mounted as tmpfs, but on /. Only if you set an option in drakboot
advanced options "clean /tmp on every boot" it will be changed to /tmpfs.

EDIT: Just checked with a fresh mga3 install, this is new with systemd,
probably related to the new privatetmp options for services and such. Added commands for that above.
This is defined in /usr/lib/systemd/system/tmp.mount

Also check /usr/lib/tmpfiles.d/tmp.conf and /usr/lib/tmpfiles.d/

OK, I will check on this.

I discovered the problem last evening, while I was doing a large video transcode in the Mageia host, and working in a total of three virtual machines (virtual networking) as the transcode went on. The VMs all came to a halt, claiming /tmp was full, and when I checked I found I also had an out-of-memory condition with my swap partition being used.

When you consider that I have 32 GB of RAM, I don't expect that to happen.

A quick check showed /tmp mounted on tmpfs, with a 16GB allocation, and completely full (from the transcode, I presume). My video wound up being truncated from /tmp filling up...while there was plenty of space on the HD where I thought /tmp would be, since that is what I had told the system to do.

I guessed that the system, on startup, determined that I had plenty of RAM so put /tmp in RAM. Well, I have ENOUGH RAM, but not plenty, as last night showed. So I need to change that setting.

I've already pinged our systemd guy, how to change that clean/properly.

Well, I bypassed the tmp.conf file as called out in the manpage, and I commented out all the mount stuff in tmp.mount. That, hopefully, should do it.

I have studied systemd a bit, but I am still not terribly familiar with it. While rooting around in these directories, I ran across a tor.service, which let me solve another minor irritation I have been experiencing. Basically, I make heavy use of TOR (the spying the US Gov't is doing motivates me to encrypt and anonymize EVERYTHING), and I also run a TOR relay here. Since deploying Mageia 3, TOR has started wrong every time I start X, and as a result, I have been manually using Vidalia to get the correct configuration file running. I had not tracked it down yet, but found the solution in tor.service. Hopefully, that problem is now gone too.

You may want to look at http://fedoraproject.org/wiki/SysVinit_ ... Cheatsheet
There's also the pretty extensive systemd for administrators series from the systemd author himself:
http://0pointer.de/blog/projects/systemctl-journal.html (just because it has the links to all the other previous ones)

You made a reference to "privatetmp options". What is that? I do understand that keeping /tmp in RAM is a higher security model (in many cases) than keeping it on a hard drive. Is this the purpose of privatetmp?

My entire system is encrypted, except for /. And, I would encrypt / if Mageia/Mandriva conveniently supported that (hint, hint) but lacking support in the installer, setting it up manually is fraught with peril. So, since / is unencrypted, I do take particular pains to prevent data leakage into an unencrypted environment. To that end, /tmp is symlinked to a fully encrypted volume, as are certain portions of /var (including /var/tmp, /var/lib/mysql, /var/www, and some others). This means that there is a period of time after pivot_root and prior to the opening of the encrypted volume where there is no /tmp available. Historically this has not been a problem.

In fact, after every upgrade, one of the first things I do is check the directory structure to make sure the upgrade hasn't stomped on my symlinks (Mageia 3 stomped on everything, BTW).

I do hope that privatetmp won't prove incompatible in any fashion with my current scheme, and if it is then I need to understand how.

jiml8 wrote:You made a reference to "privatetmp options". What is that? I do understand that keeping /tmp in RAM is a higher security model (in many cases) than keeping it on a hard drive. Is this the purpose of privatetmp?

For every service, you can enable privatetmp. This means that every service will have it's own /tmp,
from the view of the process, and it cannot see anything else in there, in case something funny happens
or if something wreaks havoc.
This private tmp is also separate from the systems physical /tmp.

You might want to read http://0pointer.de/blog/projects/security.html

In any case, you don't have to use it.

Well, I just got around to rebooting my system, specifically to deal with this /tmp issue (I tried forcing the change to /tmp on the fly but the system became VERY unhappy with me, so I just rebooted it).

It seems that I can no longer symlink /tmp to a directory on another volume; this just fails and I am getting messages that say /tmp is full. The specific message I got came out of KDE when I tried to start it, saying that ldtempconf (I think that was the name) failed, is /tmp full? Check your configuration.

So, I wound up creating a file on another volume, using losetup to configure it as a loop device, then putting a file system on it. This will work but forces me to dedicate a specific fraction of a hard drive to /tmp rather than having /tmp grow and shrink as needed, which is what I get when I just symlink to a directory. I'm rather surprised this no longer works; is this Linux-wide, or Mageia-specific? The old way was a LOT better.

Oh, also...no loop devices are being created by default when the system starts. In /dev, there is only loop-control. My losetup commands failed because loop0 did not exist. However, after I executed "losetup /dev/loop-control /myfilename", the command failed (predictably) but the loop devices were then created.

Never mind...I had the wrong file permissions on my intended tmp directory. Changing the permissions resulted in the symlink working properly

The comment about loop devices remains, however.

jiml8 wrote:Oh, also...no loop devices are being created by default when the system starts. In /dev, there is only loop-control. My losetup commands failed because loop0 did not exist. However, after I executed "losetup /dev/loop-control /myfilename", the command failed (predictably) but the loop devices were then created.

Hmmm, maybe the same underlying problem caused https://bugs.mageia.org/show_bug.cgi?id=7309
Anyways, i'd report that as a bug.