Graphical Applications Using MetaCard
A top program is a very useful thing to have on a multi-tasking operating system like Linux. You can use it to keep track of the CPU and memory usage of all programs running on the system and to detect and kill runaway processes. The character-based top program that comes with Linux systems can be improved. Because it isn't aware of the windowing system, it doesn't go to sleep when the window it is running in is iconified. It would also be nice if you could select a process to kill by clicking on it instead of having top type in its process ID.
Fortunately, Linux has a very simple and elegant way to get process information, and so it's easy to develop a graphical application to display this information using a tool like MetaCard. This article will show you how it's done using MetaCard's scripting language MetaTalk. MetaTalk is a very high level language (VHLL) that supports building complete applications with very little effort. The MetaTalk language has an English-like syntax and is very concise. This makes it easy to learn, yet doesn't sacrifice the power and compactness found in other HVLLs such as Perl. It is very readable, so it's easy for non-expert users to figure out what a script does (which can be much more difficult with languages like Perl).
Each process that is running on a Linux system has a directory in /proc. In that directory are several files containing information on the process. To implement a graphical top program, we're most interested in the information in the file named stat, which contains process run time and memory usage information. We'll also use the file named cmdline that contains the command line used to start up that process.
The stat file contains a single line of information with the fields separated by spaces. Details on the format can be found in the proc man page. Information on this page indicates that on a Linux 1.2 system, words 14 and 15 are the user and system run times, respectively, for a particular process. Word 23 is the process size in bytes, and word 24 is the number of 4KB pages currently in RAM for that process.
There are also files in the /proc system that contain information about the whole system. We'll use the /proc/stat file which contains overall system resource usage. We'll need that information to compute the percentage of CPU usage for each process.
Each time the display is to be updated, a program must do the following:
Read the stat file in the /proc directory.
Find all of the subdirectories in the /proc directory.
Read the stat and cmdline files in each of these directories.
Compute the CPU time for the process by subtracting from the last time.
Save the current CPU usage.
Convert the CPU usage into a percentage of total usage.
Build the list of processes and display it.
Schedule a time to redo the update.
The MetaTalk handler that does all of these things is called updatelist and is shown in Listing 1. This handler, like all MetaTalk message handlers, starts with the word on and the name of the message to be handled. The first few lines of this handler declare all the local variables used in this handler. While not strictly necessary, it's a good idea to declare variables to avoid bugs caused by misspelling variable names. To check your scripts, you can set the MetaCard property explicitVariables, which will flag as an error any variable used before it was declared.
The handler then gets the global system time statistics from the file /proc/stat and subtracts the values from the last time the handler was called. The time statistics are then stored in a local variable declared outside the handler, which works like a “static” variable in C. That is, it retains its value like a global, but can only be referred to within the script, so it doesn't pollute the global name space. This variable, like all MetaTalk variables, can be used as an associative array without special declarations. All you have to do is put an alphanumeric string between the  (square brackets).
Note the expressions of the form “word x of y”. These are called “chunk” expressions and are a very powerful feature of MetaTalk. With them you can access elements of a string individually without having to split up the whole string into an array first. Also note that you can add words together without having to explicitly convert them into numbers first. This saves development time and makes scripts smaller than they would be in lower-level languages.
The readfile function used in the updatelist handler is shown in Listing 2. Like all function handlers, it starts with the keyword function and is used in expressions just like MetaCard built-in functions.
There is one unusual thing about this function. Normally in MetaCard, one would use:
read from file x until eof
because when you specify eof as the terminating condition, MetaCard speeds things up by getting the file size and reading the whole file with a single system call. This doesn't work for /proc files since the stat() system call returns the file lengths as 0 bytes, even though they contain data. Therefore, we must force MetaCard to read the file a byte at a time by specifying empty as the terminating condition.
The readfile function also has to handle the case where the file specified doesn't exist, which can happen if the process exits after the ls command that obtains the directory contents is executed. It also needs to convert nulls (ASCII 0 characters) in the strings to spaces, since some of the files use this character as a delimiter. Note that this requires a scripting language that can handle binary data. MetaTalk has no problem with this, but many other scripting languages do.
The rest of the updatelist handler does steps 2 through 7 in the above recipe. The resulting listing is sorted twice to remedy one of the more annoying characteristics of the character-based top program: the individual processes bounce around the listing unpredictably if they're not using any CPU time. Instead, we'll sort them by process size and then by CPU time which is a more useful way to do it. This is only possible because MetaCard's sort is stable, which means order is preserved on sequential sorts if elements have the same key value.
Finally, the updatelist handler uses the send command to schedule a call back to itself in a few seconds and stores the ID of the timer send creates in a variable. This local variable can be used to cancel the timer using the cancel function. For example, when the application is iconified, we want to stop the processing (See Listing 3).
I snuck in a bit of object-oriented programming in the send command. The message, sent to “me”, is the object whose script is currently executing. The time interval is specified as “the update interval of me”. This object has a custom property named updateinterval that is persistent, which means it's saved whenever the object is saved. That's why you don't see any initialization of this property in these listings; it's data stored with the stack, not the code.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Returning Values from Bash Functions
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide