The /proc filesystem is one of Linux’s great features, and this article gives you a thorough grounding in some of its most useful aspects. With it, you can administer many details of the operating system without ever having to shut down and reboot the machine, which is a boon for those who need to keep their systems as available as possible.
Use the /proc Filesystem to Get a Handle on your System
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
for those who cannot write bash script.
it would be nice. but then how many people that admin a linux box that needs to be available all the time don’t know bash or perl?
One of Linux’s great features? How about SysV?
I’ve had a vague question knocking around in my mind for a while…
As far as I know, the Linux console utils like hdparm, ifconfig are just user friendly ways of generating ioctls.
A gui config tool would be just as capable of generating those same ioctls.
I know it’s not a practical proposition, would involve massive and painful duplication of work, break lightweight admin over ssh, guis are less reliable etc etc… but surely this means that in theory, Linux can be totally administered and configured without *requiring* the use of CLI tools?
There’s just no satisfying some people. The artice said that its ‘one of linux great features’ and not the ‘only great feature’. Not all linux users are gurus like some posters here but just credit to the author for spreading the knowledge. sheesh..
But a GUI config tool would be just as capable of running ifconfig and hdparm directly. Why duplicate the code and risk additional bugs or compatibility?
Linux can be administered through the GUI. You can remotely display an xterm if you need a GUI to make your configuration that much easier.
Hell 5 years ago I was administering several clusters of Linux and Solaris boxes remotely from a Windows Litestep GUI using TeraTerm ssh. I could reconfigure a cluster in less than 5 minutes.
If you can’t, well, maybe you should consider an alternate profession?
does BSD have an equivalent to /proc?
does BSD have an equivalent to /proc?
FreeBSD does have /proc, but it’s not used in quite the same way that it is in Linux. I think /proc in BSD is only used to store process ids, while /kern stores Linux-style /proc message buffers and such, though I don’t think kernfs is much used in FreeBSD. I believe procfs is being phased out due to security issues. You can get the same functionality as Linux’s /proc from the widely used sysctl command.
Thanks for responding to my idle thoughts.
I know the GUI tools in Linux use the CLI tools, but the problem is they have to parse the output. This is ok most of the time, but not ideal.
For instance, hdparm can output things like….
printf(“Unknown device type:
bits 15&14 of general configuration word 0 both set to 1.
“);
How is a gui config tool to know if this is an error, a warning, or a confirmation of the device type being recognised, without searching though a text database of hdparm’s possible responses? How can it meaningfully update it’s display to show the state of the queried device without this database?
The gui tool’s database would have to kept up to date with any modifications to any text hdparm can output, which introduces another layer of possible problems, another abstraction, and increases the size and complexity of the gui config tool by requiring this database at all.
There are many other configuration tools that also share this problem, restricting full configuration of important parts of the OS to the CLI only.
It’s probably not a good idea for hdparm (I just had a nightmarish vision of some newbie randomly clicking boxes in an hdparm gui), but there is no reason why a GUI could not do the same job? (Scripting issues aside)
BTW, I’m not a programmer or sysadmin, my profession is owning a recording studio.
//
I know the GUI tools in Linux use the CLI tools, but the problem is they have to parse the output. This is ok most of the time, but not ideal.
For instance, hdparm can output things like….
printf(“Unknown device type:ntbits 15&14 of general configuration word 0 both set to 1.n”);
//
I believe a GUI could be written to use these tools. The system return codes can be checked for errors or warnings.
! As far as I know, the Linux console utils like hdparm, ! ifconfig are just user friendly ways of generating ioctls.
! A gui config tool would be just as capable of generating ! those same ioctls.
RedHat includes many such GUI utilities in their latter releases. On my RH8.0 box, networking (ifconfig and friends), bind (DNS), time/date, webserver, printer, basic firewalling, user accounts, and email have such utilities.
OTOH I would argue that there are some things you should not do unless you really understand it. I would suggest hdparm fits this category. RedHat, and presumably other distro vendors, set reasonable defaults or allow scripts to detect hardware and configure it auto-magically. Unless you really have a reason not to futz with it, leave it alone.
Also, really there is nothing in the design of Linux/*nix that prevents GUI tools to supplement (not replace, but coexist) with CLI tools. Its just getting them written, reliable, and marketed that is difficult.
in theory, Linux can be totally administered and configured without *requiring* the use of CLI tools?
The biggest problem with GUI tools is no scriptability. You may not understand this if say you only run one system but if you are running multiple systems scripts can save enormous time. This is even more relevant in UNIX because each of those little programs can be used as a toolkit of scripting devices glued together by a scripting language such as bash or perl.
For instance I could set up ten servers to all read a specific file off of a NFS server every hour. They then can execute that script file and it tells them to write another file listing all the users logged on to their system on the NFS system. On another computer I can write a script that reads those log files and makes it into a web page that I can access. I can easily just change two files and get different loggin information off of those boxes on a webpage such as printer stats or file usage. If I gain another 100 servers all they need is that cron job to execute the logger script and I can add them as well.
That is the sort of flexibilty that the CLI system offers. Use your imagination and you can do even more complicated things. All with simple human readable text files. That is very hard to accomplish with a GUI tool.
First of all, having a GUI tool for system configuration is not an all-or-nothing proposition. Ideally, there would be GUI tools for those who don’t want to get their hands dirty (or waste time trying to learn how it all works), as well as CLI tools for those who prefer the traditional Unix way.
Second, running command line tools from a GUI front end is hard, especially in a low-level language (e.g. C, C++). Calling ioctl() then dealing with an integer return code ought to be simpler than formatting arguments, calling the command line util, then parsing various output strings. IMHO, not using the command line is the right thing to do for a system configuration GUI.
I found a project that aims to provide a true gui replacement to hdparm, ‘100% independant of hdparm’.
http://drivetweak.sourceforge.net
I’m rapidly getting out of my depth here, but as an example of GUI and CLI tools, it’s interesting…
They seem to have taken the route of using ioctls to query the device status and capabilities, so the GUI is consistent with the actual state of the device.
They have taken an approach that seems to provide a good compromise between GUI and CLI tools.
As well as directly controlling the device, the GUI app can also output a string that it’s command line hdparm equivalent can understand, so in theory you could paste it into a script, or have it added to an rc script, and use hdparm as usual.
Like most things in Linux, it’s out there if I can be bothered to look. I’m not sure how alive the project is, so perhaps there is little demand for this kind of tool.
In SysV /proc only contains process information organized by PID.
Linux has that, but also alot more information about the system.
The biggest problem with GUI tools is no scriptability. You may not understand this if say you only run one system but if you are running multiple systems scripts can save enormous time. This is even more relevant in UNIX because each of those little programs can be used as a toolkit of scripting devices glued together by a scripting language such as bash or perl.
The biggest problem is that GUI tools have no scriptability on Linux, you mean. Scriptable GUIs is nothing new at all. The rest of the computing world has had them for over a decade.
Also, there is nothing to prevent you from offering CLI and GUI interfaces in the same binary, preventing incompatibilities, sloppy code recycling and what have you. The only thing which might prevent this is certain braindead APIs still lingering in UNIX.
It seems that the CLI wizards in the UNIX world are far underestimating the power that GUIs may have, merely treating them as an afterthought and dismissing their actual potential. Think outside of the box, people!