As far as I know proc file system is a virtual file system. Is there any way to unmount the proc file system and even if I do that what will be the consequences after that.
You can check (as root) who is using a mounted filesystem like so:
fuser -m /proc
Typically, your box will not be very usable if you kill all the processes using /proc. Otherwise, there is no law saying it has to be mounted, beyond all and sundry developer assuming that it is.
umount will work like on any other file system (same conditions for a filesystem to be unmonted). You can expect a whole lot of this to stop working as soon as you do that though (including very simple utilities like ps).
Related
"The shutdown command used to kill all the running processes, unmount all the file systems and finally tells the kernel to issue the ACPI power command"
is above mentioned behaviour is same across all the file system ?
It's not clear why you are asking that, but I'll take a stab at it: Yes, all filesystems are unmounted. The code run at unmount varies per filesystem.
Does Linux need a writeable file system to function correctly? I'm just running a very simple init programme. Presently I'm not mounting any partitions. The Kernel has mounted the root partition as read-only. Is Linux designed to be able run with just a read-only file system as long as I stick to mallocs, readlines and text to standard out (puts), or does Linux require a writeable file system in-order even to perform standard text input and output?
I ask because I seem to be getting kernel panics and complaints about the stack. I'm not trying to run a useful system at the moment. I already have a useful system on another partition. I'm trying to keep it as simple as possible so as I can fully understand things before adding in an extra layer of complexity.
I'm running a fairly standard x86-64 desktop.
No, writable file system is not required. It is theoretically possible to run GNU/Linux with the only read-only file system.
In practice you probably want to mount /proc, /sys, /dev, possibly /dev/pts to everything work properly. Note that even some bash commands requires writable /tmp. Some other programs - writable /var.
You always can mount /tmp and /var as ramdisk.
Yes and No. No it doesn't need to be writeable if it did almost nothing useful.
Yes, you're running a desktop so it's needed to be writeable.
Many processes actually need a writeable filesystem as many system calls can create files. e.g. Unix Domain Sockets can create files.
Also many applications write into /var, and /tmp
The way to get around this is to mount the filesystem read/only and use a filesystem overlay to overlay an in memory filesystem. That way, the path will be writable but they go to ram and any changes are thrown away on reboot.
See: overlayroot
No it's not required. For example as most distributions have a live version of Linux for booting up for a cd or usb disk with actually using and back end hdd.
Also on normal installations, the root partitions are changed to read-only when there are corruptions on the disk. This way the system still comes up as read-only partition.
You need to capture the vmcore and the stack trace of the panic form the dmesg output to analyse further.
I understand that a file system can be visualized as a "tree" of files and directories. I also understand that "mounting" a file system means to placing or rooting that tree within an existing directory. https://askubuntu.com/questions/20680/what-does-it-mean-to-mount-something
With that said, I have mounted an implementation of python fuse that is similar to this one. When I run my implementation, it runs to the end of the init method and then just shows a blinking cursor. So fuse is getting mounted. I know that fuse is mounted because of what happens when I run $mount
$mount
...
FuseHandler on /home/memsql/mount
So now that I've mounted fuse, how do I access the files.
The linked tutorial says
You will see all files in /your/dir under /mnt/point and be able to
manipulate them exactly as if they were in the original filesystem.
How exactly do you do this? Can somebody show me, syntactically, how to instantiate and query Fuse? How do you perform a read or write? What does code that performs those operations look like?
As l4mpi notes, you’ve now mounted a file system, so it will respond to the standard Unix file system API, and FUSE will handle the file system operations. You can cd to it, ls in it, read or creat files in it, etc.
I just found out that the /proc/$pid/mem file permissions are set to read/write for the owner. Why? Does that mean that the owner can write to process memory as it runs live?
(For the record, I haven't been able to open, print or write to the contents of that file for any process I launch yet, via various means).
So why is that some of the contents in /proc are actually modifiable? Is this deliberate, or something overlooked by the Linux devs?
Much appreciated.
/proc is a directory-based view of information the kernel makes available to you.
Yes ... you can change it.
see this example :
echo "1" > /proc/sys/net/ipv4/ip_forward
you could use sysctl to configure these kernel items.
If I have a POSIX system like Linux or Mac OS X, what's the best and most portable way to determine if a path is on a read-only filesystem? I can think of 4 ways off the top of my head:
open(2) a file with O_WRONLY - You would need to come up with a unique filename and also pass in O_CREAT and O_EXCL. If it fails and you have an errno of EROFS then you know it's a read-only filesystem. This would have the annoying side effect of actually creating a file you didn't care about, but you could unlink(2) it immediately after creating it.
statvfs(3) - One of the fields of the returned struct statvfs is f_flag, and one of the flags is ST_RDONLY for a read-only filesystem. However, the spec for statvfs(3) makes it clear that applications cannot depend on any of the fields containing valid information. It would seem there's a decent possibility ST_RDONLY might not be set for a read-only filesystem.
access(2) - If you know the mount point, you can use access(2) with the W_OK flag as long as you are running as a user who would have write access to the mountpoint. Ie, either you are root or it was mounted with your UID as a mount parameter. You would get a return value of -1 and an errno of EROFS.
Parsing /etc/mtab or /proc/mounts - Doesn't seem portable. Mac OS X seems to have neither of these, for example. Even if the system did have /etc/mtab I'm not sure the fields are consistent between OSes or if the mount options for read-only (ro on Linux) are portable.
Are there other ways I'm missing? If you needed to know if a filesystem was mounted read-only, how would you do it?
You could also popen the command mount and examine the output looking for your file system and seeing if it held the text " (ro,".
But again, that's not necessarily portable.
My option would be to not worry about whether the file system was mounted read only at all. Just try and create your file and, if it fails, tell the user what the error was. And, of course, give them the option of saving it somewhere else.
You really have to do that sort of thing anyway since, in any scenario where there's even a small gap between testing and doing, you may find the situation changes (probably not to the extent of making an entire file system read only but, who knows, maybe there is (or will be in the future) a file system that allows this).
utime(path, NULL);
If you have write perms, then that will give you ROFS or -- if permitted -- simply update the mtime on the directory, which is basically harmless.