What's the deal with /proc?

[JMJ_coder]

Hello,

NetBSD has /proc in its file hierarchy, but it is empty. Do you have to do something to enable it, or is it just taking up listing space? It seems that it should be able to do something, especially since some programs in pkgsrc require it (i.e., htop).

[BSDfan666]

"/proc" is a System V thing, not really all that popular in the BSD world..

Still, What you're seeking is mount_procfs.

[IdOp]

/proc can also be mounted automatically with an /etc/fstab entry. Initially I had some trouble getting the right syntax via reading the man pages, but eventually found the following fstab entry did the trick in NetBSD 4.0:


procfs /proc procfs rw,linux


The ",linux" bit is optional.

[TerryP]

/proc is an 8th edition UNIX thing, SVR4 just made it famous.


Whether one wants to use such an interface or not is more of a taste issue imho.


binary or flat files in /proc or sysctl's, I like the file idea personally but don't really give a darn as long as the system provides documentation on what style interface to use.

[JMJ_coder]

Hello,

Thanks. I don't use the /proc system all that much - but it was brought to my attention because I wanted to try htop and it required an active /proc.

[JMJ_coder]

Hello,

binary or flat files in /proc or sysctl's, I like the file idea personally but don't really give a darn as long as the system provides documentation on what style interface to use.

Could you expand on this a little more?

[TerryP]

Unix generally provides an "every thing is a file" style of doing things.


You can read from files, you can write to files, you can ask files about themselves.


The command shell generally gives a file like interface for handling character based data streams as if they were files,


cat foo.ps | ps2ascii | sort
pkg_info > pkg_info.pre_foo_pkg



It works mostly the same way as that in the code, it really is that simple at heart.

Handing multiple processes via pipes like the shell uses are also similar in code. For example we can read from and write to a pipe (when set accordingly), just like if we ran the commands in the shell, only the user didn't have to use our program in a pipe line.


Sockets programming is really a lot like basic file input/output and related operations IMHO, just with "extra overhead" involved for the differences that connections, ports, and byte orders create, blah blah over the usual file system options.


Devices are generally implemented as block or character special files that represent an interface to the device.


If you want to print a file and redirect it's content to the printer device, say like


lptest > /dev/lpt0



Wouldn't it make sense for the lpt driver to accept writing data to it as instructions to send that data stream to the device connected ?

In essence making printing as conceptually simple as creating a stream of data the printer can understand from an input stream, then writing it out to the device. <-- don't you just love unix printing concepts?


[note: most of this is theory, I'm not familiar with the details of any current procfs implementations, nore do I wish to be since it's not common on my target systems]


So if we represent devices as files, why the hell not represent running processes as files?


That's basically what the "Process File System" or procfs is for.


Wouldn't it be cool if you wanted to kill a process by PID, and could just rm -rf /proc/PID ? Or what if you wanted to find out it's name and arguments, how about cat /proc/cmdline.



It's a simple interface to doing operating specific things. Everything is a file, so writing programs like ps, kill, and nice are just simple file I/O based on a defined file system hierarchy managed by the kernel.



I've never really used /proc because I've never used systems that required it for much but that is the value I see in it. Yes you could say I like /proc even through I hate stuff that *assumes* it is there and doesn't tell you.



Since the kernel and init are essentially processes 0 and 1 respectively if memory serves. It would make sense to have /proc/0 with files representing stuff specific to the given process, such as the kernel.

Why not use it?


Another form of interface to all that is via sysctl variables and what ever system calls are needed or desired to allow doing it from C programs.


It's just a different way of doing it.


Who cares if it is


# sysctl kern.maxproc=42




or


#echo 42 > /proc/0/maxproc




it all does the same thing, just a question of taste.


I personally feel that the second method is more "natural" and less "oh, what dang system call do I need" feeling at times. Especially on an operating system that is supposed to believe that "everything is a file".



Dang it, wouldn't it be really cool if you could do something like


# rm -f /users/luser.ptty0



and "terminate" an annoying users session on 'ptty0' >_>

[Meta_Ridley]

Wouldn't it be cool if you wanted to kill a process by PID, and could just rm -rf /proc/PID ? Or what if you wanted to find out it's name and arguments, how about cat /proc/cmdline. I know this is getting into implementation and practice, but I thought this would be helpful: that command doesn't work on NetBSD's proc filesystem. Instead you can send a signal to /proc/[pid]/ctl like this:echo term > /proc/[pid]/ctlYou can also send "attach," "detach," "run," "step," and "wait" to it, in addition to the usual process signals, and it will do all of those things.

Of course the mount_procfs(8) man page has all the info you need to find out what each file does in /proc. :)

[JMJ_coder]

Hello,

So the sysctl is the binary way and proc is the file way? And sysctl is a binary file - not a plain text file? And sysctl is the default way for NetBSD? Why would NetBSD (or any *BSD, if proc is a SVR5 thing and sysctl is a *BSD thing) do something against one of the UNIX tenets - everything is a file?

[BSDfan666]

The "ctl" utilities are a key part of BSD, they don't "ignore" the everything is a file concept.. but they also don't overuse it like Plan 9/Linux did/do.

bioctl iopctl pfctl relayctl sysctl
atactl dvmrpctl ipsecctl pppctl ripctl
audioctl mixerctl radioctl snmpctl wsconsctl
bgpctl gpioctl ospfctl raidctl swapctl usbhidctl

[TerryP]

Well, I personally doubt that the functioning of /proc on any common systems would live up to my opinions of what it should be but that's just a fact of life.


binary or flat files in /proc or sysctl's

What I meant by 'binary' was binary data stored in /proc/files rather then plain text.


sysctl is just a program used to get/set kernel state.


/sbin/sysctl, /proc/0/, /sysfs/, as long as it W_O_R_K_S ;-)

[JMJ_coder]

Hello,

I guess I am having a difficult time at the moment understanding the workings of the "ctl" utilities and proc - and their similarities and differences - and how they fit in the *BSD and SVR5 and Linux way of doing things. I'm going to try to google around to try and find more information.

[JMJ_coder]

Hello,

Also, where can I find all the options for the 'ctl' utilities and what they do? For instance, wsconsctl doesn't tell hardly any of the options (only a couple examples - which is a good start) and none of what any do - i.e., it doesn't tell you that msg.default.fg changes the text console text color.

[Meta_Ridley]

The "ctl" utilities are a key part of BSD, they don't "ignore" the everything is a file concept.. but they also don't overuse it like Plan 9/Linux did/do.I have to disagree with the "overuse" comment. Unix was originally designed to have everything accessible through the filesystem. Ironically it was the way the original BSD handled network devices that led future Unix and Unix-like OSs away from this idea. Plan 9 was/is (it's not dead; in fact it's still being actively developed, and under an open source license) a return to and an expansion on the idea, and the FUSE project is doing the same for Unix and Unix-like OSs, including NetBSD.

The idea behind using the filesystem is to give a consistent way to interact with the system, facilitating another tenet of Unix philosophy: "Do one thing and do it well." Of course many systems, for better or for worse, have gone away from that, but in general I think both using the filesystem to access everything and using small tools and putting them together instead of huge kitchen sink programs is the way I want to do things. It keeps things simple.

[BSDfan666]

Well, clearly it's a mater of preference then... for example, I don't like FUSE or /proc.

And you're wrong, UNIX has always had "devices" to be represented as files.. process information should be obtained via a system call.

[TerryP]

process information should be obtained via a system call.

Why ?


I know that File I/O like a lot of neat operations usually involves a fair bit of system calls but I assume you mean ones specific to process information ;-)



But imho, saying process information should be obtained via a system call, in the sense of a system call or system calls specifically designed just for the express purpose of pumping out that information. Is like saying bytes must be 8-bits long on every machine ever made.


It probably should be that way but people should also be free to try new and different things.

[Meta_Ridley]

Well, clearly it's a mater of preference then... for example, I don't like FUSE or /proc.I'm glad we agree on something.

And you're wrong, UNIX has always had "devices" to be represented as files.. process information should be obtained via a system call.I'm guessing what you meant to say was that process information has been traditionally obtained via a system call. Is that correct? In any case, saying something is the way it is and saying what something should be are two different things. In essence by saying this you've contradicted your above statement, since by saying process info should be obtained via a system call you're leaving no room for others' preferences. What if someone created a Unix fork that had only the /proc filesystem and no system calls to get process information and prefers it be that way? Would you leave them alone, saying it's their preference and the preference of its users, or would you chastise them because they're not doing what you think they should do?

And yes, I made a mistake in saying that all information on the system was represented as files. That's true of devices, but not of processes until /proc came along.

[BSDfan666]

Heat of the moment, of coarse... apologies. ;)