Description of problem: MCC->System->Services does not preserve my enable/disable choices for the systemd-tmpfile-setup and systemd-tmpfile-clean services. Version-Release number of selected component (if applicable): drakconf-12.38-1.mga3 How reproducible: Very. Steps to Reproduce: 1. Start MCC, select System, then Services 2. uncheck the boxes to enable systemd-tmpfile-* at boot 3. Save the results 4. Select Services again 5. The tmpfile services enable boxes are checked again 6. Quit MCC 7. Restart MCC 8. Same as step 5 here (i.e., hoping a quit-save might work did not help) From the command line, I try to use the systemctl disable command on these. The systemd-tmpfile-clean service issues a message when disabled that the systemd-tmpfile-timer service can restart the clean service again. Disabling the systemd-tmpfile-setup service does nothing either. It is understood that the tmpfile service is needed to ensure that there is a /tmp directory available at boot. However, this is not necessarily what a user wants; the tmpfs that systemd-tmpfile-setup creates is limited to 1/2 GB, and it is in memory (or maybe swap, not sure). A user might like to use their hard disk space for tmp files, but unless there is a way to disable these services, it cannot be done. When applying filtering rules for Thunderbird's inbox, which has several thousand messages, the /tmp device fills up with temp files. Even using something like TMP=$HOME/tmp thunderbird & from the commandline does not seem to work. (Same for TEMP=...). The system nearly crashes but for noticing the problem in time, and removing the temp files generated by thunderbird. Another workaround for thunderbird is appreciated, but solving the systemd/MCC Services issue should be a higher priority. It seems reasonable to be able to disable nearly any system service, with the caveat that some capabilities of the system may be impacted as well. However, using /tmp on the root or other disk file system versus tmpfs should be transparent to most processes. Reproducible: Steps to Reproduce:
(In reply to bozonius from comment #0) > When applying filtering rules for Thunderbird's inbox, which has several > thousand messages, the /tmp device fills up with temp files. Even using > something like > > TMP=$HOME/tmp thunderbird & I think an mcc setting will fix that problem. If not set a few other variables. Set user tmp via mcc->Security->Configure system security, permissions and audit click System security tab and set secure_tmp = yes Some applications use different variables for temp storage location. For those I created /etc/profile.d/xx_local.sh with the following: #!/bin/bash export TMP=$HOME/tmp export TMPDIR=$TMP export TEMP=$TMP export GCONF_TMPDIR=$TMPDIR export KDETMP=$TMP export KDEVARTMP=$TMPDIR mkdir -p $TMPDIR #******* end xx_local.sh ************* Then chmod +x /etc/profile.d/xx_local.sh Now log out/in and see what happens.
CC: (none) => junk_no_spam
Bit: Thanks for the suggestion. Changing the setting to secure_tmp didn't help (unless I need to logout again first? I wouldn't think so for that). As far as the other suggestion, it sounds helpful if I am running Gnome or KDE. Of course, I could try to figure out what the TMP and TMPDIR settings should be for LXDE (I don't even have Gnome or KDE installed). Apparently, from what I read, TBird uses $TMP, and that doesn't work. But I'll give TMPDIR a try. (I also changed a tempfile setting in about:config, but that didn't help either). I think the main thing is getting this bug corrected so much of this workaround-workaround-workaround could be avoided entirely. I do appreciate your suggestions and I might add that xx_local.sh business to my system (good tip).
CC: (none) => bozonius
Bit: I tried TMPDIR instead of TMP and it works. Now I just have to figure out how to get LXDE to handle this in the launcher (panel). I may have to write a short wrapper; it looks like it currently runs a binary directly. Thanks again. Still need to see the bug fixed though.
(In reply to bozonius from comment #3) > Bit: I tried TMPDIR instead of TMP and it works. Now I just have to figure > out how to get LXDE to handle this in the launcher (panel). I may have to > write a short wrapper; it looks like it currently runs a binary directly. > Thanks again. Still need to see the bug fixed though. Turns out I can just specify "env TMPDIR=/home/hank/tmp thunderbird %u" in the properties for thunderbird from the lxde menu. Maybe this info is handy for others needing a similar fix.
In a separate test VM, I discovered that if I explicitly create a /tmp during install, M3 uses that instead of the tmpfile service; in fact, it appears that the service is not even installed. So a new workaround for existing installs: If VM install, try adding a drive to the VM for /tmp If HW install, maybe try repartitioning the disk with a tool like parted magic I have not tried either of these (yet) so I cannot aver whether these work.
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD