Dear Linux Experts,
I've recently passed from Fedora 20 to Fedora 23 on my laptop.
I've a separate partition for /tmp that I'm used to see it wiped out at any reboot on my previous installation but now this is never wiped out.
This is a real partition:
/dev/sda10 5029504 1154204 3596772 25% /tmp
whereas previously it was a tmpfs partition. I've read on the web that after Fedora 20 the tmpfs has been dropped in favor of real partition but I was expecting anacron/cron entry that wipe the content of the partition at boot but my system doesn't have any.
It is also difficult to create my own anacron/cron entry because this should take effect before the system starts and create its temp files/sockets in there.
I'm also puzzled because I also have a couple of tmpfs partitions:
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 16 1633624 1% /run/user/526
that I don't what they are for and if I can (and how) rid of them.
Probably I could add an entry like this tmpfs /tmp tmpfs rw,seclabel 0 0
in /etc/fstab but this would means a waste of the space I currently have reserved for /tmp (4Gb not much but I would prefer to use them).
So there is a way to wipe out the /tmp partition before it has been mounted and the system creates its files and use the current partition for it?
Thank you Walter
--
On Wed, 2016-01-27 at 20:29 +0100, Walter Cazzola wrote:
Dear Linux Experts,
I've recently passed from Fedora 20 to Fedora 23 on my laptop.
I've a separate partition for /tmp that I'm used to see it wiped out at any reboot on my previous installation but now this is never wiped out.
This is a real partition:
/dev/sda10 5029504 1154204 3596772 25% /tmp
whereas previously it was a tmpfs partition. I've read on the web that after Fedora 20 the tmpfs has been dropped in favor of real partition but I was expecting anacron/cron entry that wipe the content of the partition at boot but my system doesn't have any.
It is also difficult to create my own anacron/cron entry because this should take effect before the system starts and create its temp files/sockets in there.
I'm also puzzled because I also have a couple of tmpfs partitions:
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 16 1633624 1% /run/user/526
that I don't what they are for and if I can (and how) rid of them.
Probably I could add an entry like this tmpfs /tmp tmpfs rw,seclabe l 0 0
in /etc/fstab but this would means a waste of the space I currently have reserved for /tmp (4Gb not much but I would prefer to use them).
So there is a way to wipe out the /tmp partition before it has been mounted and the system creates its files and use the current partition for it?
I did a fully default install in a Virtualbox using: Fedora-Workstation-netinst-x86_64-23.iso
That install did use tmpfs for /tmp as seen below.
[root@localhost temp03]# df Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 1014436 0 1014436 0% /dev tmpfs 1024720 308 1024412 1% /dev/shm tmpfs 1024720 1184 1023536 1% /run tmpfs 1024720 0 1024720 0% /sys/fs/cgroup /dev/mapper/fedora-root 10504444 5544500 4403300 56% / tmpfs 1024720 48 1024672 1% /tmp /dev/sda1 487652 243549 214407 54% /boot tmpfs 204944 36 204908 1% /run/user/1000 [root@localhost temp03]# uname -a Linux localhost.localdomain 4.2.8-300.fc23.x86_64 #1 SMP Tue Dec 15 16:49:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@localhost temp03]# cat /etc/fedora-release Fedora release 23 (Twenty Three)
If tmpfs is still the standard then that should explain why it is not cleaning it. As for how to run a shutdown version of rc.local it looks like it is pretty well expained in the first few hits using:
fedora run script at shutdown
Looks like you just create your own script (could call it rc.local.shutdown) and wrap it into a new systemd service.
On Wed, Jan 27, 2016 at 08:29:57PM +0100, Walter Cazzola wrote:
Dear Linux Experts,
I've recently passed from Fedora 20 to Fedora 23 on my laptop.
I've a separate partition for /tmp that I'm used to see it wiped out at any reboot on my previous installation but now this is never wiped out.
This is a real partition:
/dev/sda10 5029504 1154204 3596772 25% /tmp
whereas previously it was a tmpfs partition. I've read on the web that after Fedora 20 the tmpfs has been dropped in favor of real partition but I was expecting anacron/cron entry that wipe the content of the partition at boot but my system doesn't have any.
It is also difficult to create my own anacron/cron entry because this should take effect before the system starts and create its temp files/sockets in there.
I'm also puzzled because I also have a couple of tmpfs partitions:
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 16 1633624 1% /run/user/526
that I don't what they are for and if I can (and how) rid of them.
Probably I could add an entry like this tmpfs /tmp tmpfs rw,seclabel 0 0
in /etc/fstab but this would means a waste of the space I currently have reserved for /tmp (4Gb not much but I would prefer to use them).
So there is a way to wipe out the /tmp partition before it has been mounted and the system creates its files and use the current partition for it?
Couple of points. I don't think you can reserve a partition for the use of a tmpfs. It uses your RAM memory and swap space instead.
You could add /dev/sda10 as another swap partition. Then perhaps add the fstab entry. However, I think systemd has a way mount /tmp as a tmpfs without having an fstab entry.
If you want to use your partition as /tmp but have it cleaned out at boot, check the manpage for tmpfiles.d
Jon
On 01/27/2016 11:29 AM, Walter Cazzola wrote:
I've a separate partition for /tmp that I'm used to see it wiped out at any reboot on my previous installation but now this is never wiped out.
That's the expected behavior. If you specify a partition during install, it will be used. If you use the default layout, you'll get tmp on tmpfs. There's no active wiping involved, either way. tmpfs simply isn't persistent.
If you'd like to use tmpfs now, you can "systemctl enable tmp.mount" and comment out the /tmp item you currently have in fstab. When you reboot, you should have /tmp mounted as tmpfs.
Once you've done that, you can remove the partition or LV that you're using for /tmp now. Then you can resize another LV to use the free space or, if you're not using LVM, try to figure out how to do something useful with the space.
On Wed, 2016-01-27 at 15:06 -0500, Jon LaBadie wrote:
I don't think you can reserve a partition for the use of a tmpfs.
You don't. You mount a tmpfs on top of a directory. Once mounted, any attempt to access that directory goes into the temporary file system that you mounted there. Any files that were in the directory become inaccessible.
If you want to use your partition as /tmp but have it cleaned out at boot, check the manpage for tmpfiles.d
There are some advantages to persistent /tmp files (such as if debugging information stays in there until you've used it). The old idea, when it worked, was to leave files in there and delete them a few days after they were created, or a few days since they were last read (using a cron job, to automate that).
Though waiting for a few days of them not being read could last forever, in some cases. You only have to open the /tmp directory in a file browser, and the filebrowser will look into each file to see what they are, and that means that they've been "read". Likewise for anything else that scans the directory tree, and goes through /tmp.
Ok I dropped the idea of using my current /tmp partition for a tmpfs and followed your suggestion
On Wed, 27 Jan 2016, Gordon Messmer wrote:
If you'd like to use tmpfs now, you can "systemctl enable tmp.mount" and comment out the /tmp item you currently have in fstab. When you reboot, you should have /tmp mounted as tmpfs.
unfortunately this didn't work
> systemctl enable tmp.mount The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...).
But I've solved it by manually adding tmpfs /tmp tmpfs rw,seclabel 0 0 to /etc/fstab and commenting the line used to mount the old /tmp partition.
I still have to rid off of one of these two tmpfs
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 20 1633620 1% /run/user/526
I think I have to keep one of them since it is associated to my id (526) but I can't imagine what the other is for and how to avoid its creation. Googling didn't help much.
Thanks Walter
--
On 01/28/16 18:46, Walter Cazzola wrote:
I still have to rid off of one of these two tmpfs
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 20 1633620 1% /run/user/526
I think I have to keep one of them since it is associated to my id (526) but I can't imagine what the other is for and how to avoid its creation. Googling didn't help much.
You will not want to, or be able to, get rid of those.
/run is itself a tmpfs and the /run/user/$uid are created as needed by systemd, I think. This stores temporary associated with a user's running processes that only the user should have access to. Placing that info in /tmp or another area may present a security issue. /run/user/$uid is restricted to that particular UID.
On Thu, Jan 28, 2016 at 11:46:49AM +0100, Walter Cazzola wrote:
Ok I dropped the idea of using my current /tmp partition for a tmpfs and followed your suggestion
On Wed, 27 Jan 2016, Gordon Messmer wrote:
If you'd like to use tmpfs now, you can "systemctl enable tmp.mount" and comment out the /tmp item you currently have in fstab. When you reboot, you should have /tmp mounted as tmpfs.
unfortunately this didn't work
systemctl enable tmp.mount
The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are:
- A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory.
- A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it.
- A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...).
But I've solved it by manually adding tmpfs /tmp tmpfs rw,seclabel 0 0 to /etc/fstab and commenting the line used to mount the old /tmp partition.
I still have to rid off of one of these two tmpfs
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 20 1633620 1% /run/user/526
I think I have to keep one of them since it is associated to my id (526) but I can't imagine what the other is for and how to avoid its creation. Googling didn't help much.
Don't remove either one. They are managed by the system. They are taking no disk space (unless memory becomes full and it will then use swap). They are not even taking significant memory. In fact 989 is using 0 memory. Why are you so intent on removing things working as they should?
Probably user 989 is your login display manager. Check who 989 is in /etc/passwd (grep 989 /etc/passwd). On my system is it "lightdm". I have a /run/user/966. My 966 is "sddm", my display manager.
jl
On Thu, 28 Jan 2016, Jon LaBadie wrote:
I still have to rid off of one of these two tmpfs
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 20 1633620 1% /run/user/526
I think I have to keep one of them since it is associated to my id (526) but I can't imagine what the other is for and how to avoid its creation. Googling didn't help much.
Don't remove either one. They are managed by the system. They are taking no disk space (unless memory becomes full and it will then use swap). They are not even taking significant memory. In fact 989 is using 0 memory. Why are you so intent on removing things working as they should?
Probably user 989 is your login display manager. Check who 989 is in /etc/passwd (grep 989 /etc/passwd). On my system is it "lightdm". I have a /run/user/966. My 966 is "sddm", my display manager.
Indeed you are right, this is sddm, I was thinking it was something related to some other users I dismissed but it seems it is not the case.
Thanks for the grep suggestion I couldn't image it was something really in use.
Walter
--
On 28 January 2016 at 16:19, Walter Cazzola cazzola@di.unimi.it wrote:
On Thu, 28 Jan 2016, Jon LaBadie wrote:
I still have to rid off of one of these two tmpfs
tmpfs 1633640 0 1633640 0% /run/user/989 tmpfs 1633640 20 1633620 1% /run/user/526
I think I have to keep one of them since it is associated to my id (526) but I can't imagine what the other is for and how to avoid its creation. Googling didn't help much.
Don't remove either one. They are managed by the system. They are taking no disk space (unless memory becomes full and it will then use swap). They are not even taking significant memory. In fact 989 is using 0 memory. Why are you so intent on removing things working as they should?
Probably user 989 is your login display manager. Check who 989 is in /etc/passwd (grep 989 /etc/passwd). On my system is it "lightdm". I have a /run/user/966. My 966 is "sddm", my display manager.
Indeed you are right, this is sddm, I was thinking it was something related to some other users I dismissed but it seems it is not the case.
Thanks for the grep suggestion I couldn't image it was something really in use.
Incidentally whilst you're in the middle of cleaning up the system you really should move your UID to something over 1000 ...
There's a lot of stuff that no longer works as expected with a UID around 500 (have you checked you login.defs recently)?
Seeing a display manager with a UID higher than your own ought to be a warning sign ;)
On 01/28/2016 02:46 AM, Walter Cazzola wrote:
On Wed, 27 Jan 2016, Gordon Messmer wrote:
If you'd like to use tmpfs now, you can "systemctl enable tmp.mount" and comment out the /tmp item you currently have in fstab.
unfortunately this didn't work
systemctl enable tmp.mount
The unit files have no [Install] section. They are not meant to be enabled using systemctl.
That's weird...
# tail -3 /usr/lib/systemd/system/tmp.mount # Make 'systemctl enable tmp.mount' work: [Install] WantedBy=local-fs.target
But I've solved it by manually adding tmpfs /tmp tmpfs rw,seclabel 0 0 to /etc/fstab and commenting the line used to mount the old /tmp partition.
Obviously that works, but it'll be mounted later in the boot process.
Thinking about it... it's possible that /tmp on tmpfs is actually mounted by default, without needing to "enable" it specifically, and that the only requirement is that you don't specify any other filesystem for /tmp in fstab. If you're curious, try it. Comment out /tmp in fstab and see what you get when you reboot.
-
Doug H. -
Ed Greshko -
Gordon Messmer -
James Hogarth -
Jon LaBadie -
Tim -
Walter Cazzola