Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am putting some configuration files on a ramdisk (ramfs) to make sure they disappear on shutdown.
But I got to thinking if something went wrong and the files got copied to the mount point /mnt/tmpfs vs. the ramdisk, how can you tell?
Is the file virtual or not?
I did the umount -v /mnt/tmpfs and attempted to wipe the mount point directory & but it said access denied so I am guessing it really wasn't dismounted.
Got any ideas Experts?
Last edited by HardenedCriminal; 07-04-2015 at 12:25 PM.
Reason: It is a RAMFS ramdisk not a tmpfs.
While the tmpfs filesysem is mounted, you can run "df /mnt/tmpfs? and see if the filesystem type in the first column is "tmpfs".
While the tmpfs is not mounted, you can just look in the /mnt/tmpfs directory and see if anything is there. Even while the tmpfs is mounted, there is still a way to see if any files are hidden under that mount point. Look at the manpage for the mount command and read the section about "The bind mounts."
Without knowing exactly what you did when you "attempted to wipe the mount point directory," it's hard to know what might result in "access denied" (or whatever the actual error message was).
You can always run df on a file of interest to see what drive it lives on, eg: "df /mnt/tmpfs/tempfile". Or as rknichols suggested, you can run df on the directory itself to see were it lives.
It won't unmount if some process has an open file or a current working directory there. If "umount -v" says the filesystem was unmounted but you are still seeing the files, then they must have been created by a process that was running in that mountpoint directory before the ramfs (or tmpfs) was mounted on it, and thus were never in the ramfs at all.
For the purposes of this discussion, ramfs and tmpfs are equivalent. The major difference is that tmpfs pages can be swapped out, whereas ramfs pages are locked in RAM. A ramdisk is different from either of those. A ramdisk simulates a fixed size hard disk in RAM, and you use mkfs to create an ordinary filesystem on it. df would show the type of whatever filesystem you created there, not "tmpfs" or "ramfs".
What is odd about all this, is I did disable the program that makes and loads the ramdisk to find nothing in the /mnt/tmpfs/ folder on reboot. On my remote servers, I don't have this option.
I am to say the least confused. All I can figure is that all the files are cached into memory even though I can't find them once I umount the drive and squid still working. I think I will make a little program to run before Ramdisk is loaded to make sure the /mnt/tmpfs folder and its contents are deleted.
Last edited by HardenedCriminal; 07-04-2015 at 08:07 PM.
When you remove a file, all that directly happens is that the directory link to that file is deleted. The file remains allocated in the filesystem until (a) the count of hard links to that file goes to zero, and (b) no process has the file open. Squid can continue running and using those deleted files. You won't be able to see them in the filesystem (no directory links), but you can still actually open the files by following the symlinks in /proc/{PID}/fd. You won't be able to unmount the filesystem (error EBUSY, "device is busy") while there is an open file there.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.