14th March 2011, 11:14 PM
/dev/sda9 on /tmp type ext4 (rw,relatime,barrier=1,data=ordered)
/dev/sda9 on /var/tmp type ext4 (rw,relatime,barrier=1,data=ordered)
/dev/sda9 16G 5.7G 10G 37% /tmp
/dev/sda9 16G 5.7G 10G 37% /var/tmp
sda9 is my swap partition. And I'd like to know WHY those folders are stored on that partition? Or are they in RAM and saved to swap automatically at shutdown? I really can't get the logic behind it...
The other thing is: In fstab there's nothing about it? Normally I'd store at least /var/tmp on a tmpfs drive in RAM. That's faster and my harddrive can shutdown often :)
Who can help ?
EDIT: I have to correct myself!
/dev/sda9 isn't swap! It's a partition I've never recognized before?! fdisk says that it exists... strange.
So.. there are still questions:
1. how can 1 partition be mounted at TWO places?
2. I checks the used storage at /var/tmp and /tmp. Together its about 500MB. But "df -h" says there are 6GB used. Where are those? How can I see what's really been stored?
15th March 2011, 12:36 AM
Try this instead of df
du -h /tmp
This directory is used to store stuff for programs that are active. Burn a DVD with k3b, for instance, and it needs to save a copy of the stuff you're burning there. That way it can't damage the original. Google "/tmp" for more.
15th March 2011, 12:43 AM
What system are you running.
Fedora doesn't do this unless you specifically configure it to.
It is possible to have the same mount twice, but in reality it is only once, and the second one is a "bind" mount - which ties a directory in a filesystem to a mountpoint. The mountpoint becomes a redirection to the real directory. In this case the "real directory" is a mountpoint.
15th March 2011, 03:46 PM
I already knew what /tmp is for ;) That's not the problem.
I'd like to know WHERE it really saves the files (HDD or RAM) ?!
"df -h" now says: 5.8 GB in use.
now comes "du -h":
# du -h /tmp
# du -h /var/tmp
That's FAR away from 1GB ;) ...
My system is: 2x2.0 GHz Core 2 Duo (Mobile), Intel ICH 9 Chipset, Nvidia 9600M GT, 4GB DDR3-1066, 320GB HDD
Device Boot Start End Blocks Id System
/dev/sda1 * 63 134223074 67111506 7 HPFS/NTFS/exFAT
/dev/sda2 134223075 150994934 8385930 7 HPFS/NTFS/exFAT
/dev/sda3 150994935 625137344 237071205 5 Extended
/dev/sda5 150995061 151268039 136489+ 83 Linux
/dev/sda6 184827888 201599684 8385898+ 82 Linux swap / Solaris
/dev/sda7 201599748 490914269 144657261 83 Linux
/dev/sda8 490914333 625137344 67111506 7 HPFS/NTFS/exFAT
/dev/sda9 151271424 184825855 16777216 83 Linux
sda5 is /boot
sda6 is swap
sda7 is /home
sda9 is /
EDIT: ---> MY FAULT!!!
/dev/sda9 is root. Now I know where the rest of my HDD-space is ;)
BUT: Why are those entrys in "mount" and "df -h" and not in "/etc/fstab" ???
15th March 2011, 04:24 PM
Because they are in /etc/mtab.
The question is how did they get there.
Fedora doesn't use bind mounts, and unless the /etc/mtab is contaminated (possible, it is updated on every mount/umount, but rarely recreated).
/etc/mtab is nearly, but not always the same as /proc/mounts, and some distributions, I've herd, make a symbolic link for /etc/mtab.
mtab is only used for tracking current mounts done by the mount/umount utility. It is entirely possible to add bogus entries.
Normally (at least in the past, didn't find it in F14) mtab was erased by entering the first mounted file system (root, read only, remember) after it has been remounted read/write. This used to be in a startup shell script (a simple ">/etc/mtab" was all that was needed) to create an empty file, sometimes this would be replaced by ... echo "<rootdev> / <type> <rw> 0 0" >/etc/mtab, or it would just append it, thus making the initial list of mounted devices. mount/umount would then update it for each additional mount.
There are a number of mounts that will not show up in the mount list (which is taken from /etc/mtab). Mounts for udev, nfsd, gvfs-fuse-daemon... On my system, /etc/mtab has 16 entries, but /proc/mounts has 21.
The /proc/mounts has the number of mount system calls that have been done, the /etc/mtab file has the record of mount/umount utility iactions (or have faked entries).
15th March 2011, 05:12 PM
There they are:
# cat /etc/mtab
rootfs / rootfs rw 0 0
/proc /proc proc rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=2018480k,nr_inodes=504620, mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
/dev/sda9 / ext4 rw,relatime,barrier=1,data=ordered 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/ns cgroup rw,nosuid,nodev,noexec,relatime,ns 0 0
cgroup /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0
cgroup /sys/fs/cgroup/cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
systemd-1 /dev/hugepages autofs rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,ma xproto=5,direct 0 0
systemd-1 /dev/mqueue autofs rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,ma xproto=5,direct 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,ma xproto=5,direct 0 0
systemd-1 /sys/kernel/security autofs rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,ma xproto=5,direct 0 0
systemd-1 /sys/kernel/debug autofs rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,ma xproto=5,direct 0 0
tmpfs /media tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec,relatime,mode=775,gid=54 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
/dev/sda5 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0
/dev/sda7 /home ext4 rw,relatime,barrier=1,data=ordered 0 0
/dev/sda9 /tmp ext4 rw,relatime,barrier=1,data=ordered 0 0
/dev/sda9 /var/tmp ext4 rw,relatime,barrier=1,data=ordered 0 0
/dev/sda7 /home ext4 rw,relatime,barrier=1,data=ordered 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,relatime 0 0
My mtab has a whole lot more things mounted than yours ;)
And this is mtab:
# ls -l /etc/mtab
lrwxrwxrwx. 1 root root 12 Mar 11 12:56 /etc/mtab -> /proc/mounts
So it IS in mtab, and mtab == /proc/mounts. As far as I know this is a requirement for systemd!
I think it could have sth. to do with systemd, which is new in F15. At least "systemctl" gives me 2 systemd-units that have sth. to do with /tmp and /var/tmp.
systemctl | grep tmp
tmp.mount loaded active mounted /tmp
var-tmp.mount loaded active mounted /var/tmp
I still can't imagine why those mounts happen. Without them the files would be at sda9 and with them they are at sda9, too. Sense?
EDIT: I can't find those tmp.mount and var-tmp.mount files... all other systemd units are in /lib/systemd/... but those two aren't
15th March 2011, 09:06 PM
I have systemd-20 (most recent "stable" release) installed at my girlfriends notebook. It's Gentoo Linux. And there's no such behaviour. Though i think it's Fedora specific.
have you F15 or Rawhide installed? If "yes" then you should also run systemd. have you somewhere filed named "var-tmp.mount" and "tmp.mount" ?
24th March 2011, 08:25 PM
You might want to look in /etc/tmpfiles.d . One of the things changing is removing the need for programs to use sudo bit. The pid directory is kind of caught in the crossfire right now as the pid directory is now in a tmp directory but applications are supposed to use subdirectories to use subdirectories to hold their actual pid files. Those sub directories don't exist for all applications right now.
MySQL is one that has been causing me gas. It wouldn't start because it's subdirectory didn't exist so it had no where to create the pid file.I went in and created the directory myself and changed the permissions but when I rebooted it was gone as it is just memory. The issue is who should be adding those sub directories the application or the package that creates the file system skeleton? Normally you would set up your application to create the directory if it didn't exist. But with out the sudo bit the application can no longer do that. The solution was to add a file
Then add the line
d /var/run/mysqld/ 0755 mysql mysql -
That tells the OS to add a directory at that location give it the 755 permissions and it should be owned by mysql.mysql
The cgroups are created by the libcgroup package.
24th March 2011, 08:44 PM
I don't know where you got mysql... but mine doesn't require anything like a /etc/tmpfiles.d - that doesn't exist on my system (F14).
The MySQL startup defines all of these parameters on the command line that starts the daemon.
And there is no such thing as a sudo bit... there IS a setuid bit, but to use it you need to flag the file with a SELinux label, or it won't go. This is to prevent attacks from packed archive files that may get restored...
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.