| CONTENTS |
Summary BoxWe've already talked about so many of the topics in this chapter, here or there, that it may seem like a real hodgepodge. It's a grab-bag of important things to know about processes which you can think of as programs that are actually running, rather than sitting on the disk somewhere. The chapter starts out with a couple of conceptual articles. They define some important terms that you're likely to encounter in this chapter. Then we talk about the ps command, which tells you what processes you have running and just what they are up to (Section 24.5, Section 24.6, Section 24.8). The next few articles cover signals, which are one way processes communicate with one another. We cover topics like:
We go from there to a more general discussion of ways to kill processes:
TOR |
We discuss fork and exec in Section 27.2, but the concept comes up so often in this chapter that we thought we ought to have a closer cross reference.
Put simply, fork and exec are the Unix system calls (requests for operating system services) that Unix programs use to create new processes. When you start up a Unix system, it starts with only one process, a program called init.
How does init magically turn into the hundreds or perhaps even thousands of processes that make up a working Unix system? That's where fork and exec come in.
One process spawns another ("spawn" is another term you should get used to seeing) either by replacing itself when it's done an exec or, if it needs to stay around, by making a copy of itself a fork. In the latter case, the forked copy commits polite suicide by execing the desired second program.
A good example of this whole sequence can be seen in the way a Unix system's login procedure for terminals (non-network (Section 1.21) logins) works. The init process spawns a series of getty processes, each of which monitors a serial port (a tty), looking for activity. It's the getty program that actually puts up the first login: prompt.
Once someone actually types a login name, getty's job is done; it execs the login command. login prompts for a password (if the account has one) and, if the password is okay, execs the login shell. Whenever you start another program, the shell forks itself, and the copy execs whatever program you asked to run.
That's why some commands are built into the shell (Section 1.9). There's overhead involved in starting a new process. What's more, because a child process can't affect its parent's environment (Section 24.3), some commands don't make sense as separate processes. For example, cd must be built in, or it couldn't change the working directory for the current shell.
There's an exec command that you can type at a shell prompt; see Section 36.5. Watch out, though: it will replace your shell with whatever command you exec, with no going back. This is useful only if you want to replace your shell with some other interactive command interpreter with similar powers, or if you'll be ready to log out when the command you exec finishes.
TOR
As you know, when you log into your Unix account and start typing, you're talking to the shell (Section 27.1). The shell you use may be a variant of the Bourne shell (such as a standard sh, ksh, or the GNU shell bash), or perhaps it is a variant of the C shell, csh (such as, perhaps, the tcsh shell that includes line- and history-editing features). Alternatively, you may be using a somewhat less common shell such as rc.
Your shell is a process, one of many individual programs running at the same time on the machine. Every process has certain pieces of information associated with it, including the following:
The process ID (PID) is a number assigned to the process when it is started up. Process IDs are unique (that is, they cycle and are eventually reused, but no two processes have the same process ID at the same time).
The user ID (UID) tells who the process belongs to. This determines what files and directories the process is allowed to read from or write to (Section 50.1), as well as who is allowed to kill the process (Section 24.12) (tell it to stop running).
The group ID (GID) is similar to the user ID but tells which group the process belongs to. On some systems, this controls the group assigned to files created by the process. See Section 50.2.
The environment contains a list of variable names and associated values. For example, when you type echo $HOME at the shell and it prints out the name of your home directory (Section 1.15), it has told you the contents of the environment variable (Section 35.3) called HOME.
The current working directory (Section 31.3) is the directory that is currently the default. When you specify a filename to a program but do not say explicitly where to look for it with a pathname (Section 31.2), the program will look in the current working directory if the PATH variable contains the current directory (Section 35.6 explains).
File descriptors are a record of which files a process has opened for reading or writing, as well as the current position in each file.
Versions of Unix with job control (Section 23.1) have process groups. A process group is used for distribution of signals (Section 24.10, Section 24.11, Section 24.14). It's also used to control which process can read from a terminal. A process that has the same process group as the terminal is "in the foreground" and can read from the terminal. Other processes are stopped when they try to read from the terminal.
When you're typing commands at the shell, it is the controlling process of your terminal, meaning that it (the shell) is the process that gets the input you type. See Section 24.6.
Normally, when you type a command at the shell prompt, that command runs and is allowed by the shell to take over the terminal for its lifetime. For example, if you type more .login to view your .login file, the shell starts up the more program and then sits around waiting for it to finish; while more is running, you can type commands to page through the file and more (not the shell) will see them. The command you run is called a child or subprocess of the shell process, which is its parent. All process information (user ID, group ID, etc.) is inherited by the child from its parent, except for the process ID, since the child is assigned a new one. Built-in shell commands (Section 1.9) such as cd don't start a child process.
Although the normal behavior is for the shell to wait until any command you run has finished before it becomes active again, there are some situations in which you don't want this to occur. For example, if you're using a window system such as X (Section 1.22) and want to start up a new xterm window from your shell, you don't want to type just xterm, because then your original shell will wait until the xterm finishes before allowing you to type any more commands. This would mean that you still have only one shell to work in, thus defeating the purpose of starting the new xterm.
When you don't want a process to finish before getting back to the shell, you can run it in the background. You do this by putting an ampersand (&) character at the end of the command, for example, xterm &. The shell will start the child process and then immediately prompt you for another command. Note that in this situation, the shell retains control of the terminal, and the newly created background process cannot read input. Some shells have additional job control (Section 23.1) features (processes that are running in the background are often described as background jobs or just jobs) that enable you to do things such as kill jobs or bring a job from the background into the foreground so that it becomes the controlling process of the terminal and you can type input at it.
An important thing to remember is that although process information is inherited by children when they are started, it is impossible for the parent to affect its child's process information (or vice versa) after that point. For example, if you start up the editor vi, suspend it (Section 24.6), and then use the cd command in the shell to change directories, vi will still have the old working directory when you bring it back into the foreground. Similarly, if you write a shell script that changes some environment variables, those variables will contain their old values in the shell when the shell script exits. This sometimes confuses MS-DOS users, since MS-DOS stores information such as the current directory in a global area that is referenced by all programs. If it is necessary to communicate information from a child back to a parent shell, other methods are needed (Section 24.10, Section 35.29).
One more useful concept: when a process exits, it returns a numeric exit status (Section 35.12) to its parent process. By convention, a zero status means success; nonzero means some kind of failure.
Just as there are ways to modify the environment and the current working directory of the shell, there are also useful ways to manipulate file descriptors (Section 36.16).
JIK
In Unix, when a program starts another program (more exactly, when a process starts another process), the new process runs as a subprocess (Section 24.3) or child process.[1] When a shell starts another shell, the new shell is called a subshell.[2]
So what? There are some important things to know about it: the child process gets a copy of its parent's environment, and any changes in the environment of the child process aren't passed to its parent. "Still," I hear you say, "so what??"
Shell scripts are run in a subshell (unless you use the source or . commands (Section 35.29) to start the script). If the script makes changes to the environment of its (sub)shell, the parent shell won't see those changes. If the script uses cd, it doesn't change the current directory in the parent shell. If the script changes the value of the TZ (or any) environment variable, that won't change TZ in the parent shell. The script can set a different umask than the parent shell no problem.
There are times you might want to start a subshell from your current shell. Maybe you have a special project where you need to work in a different current directory, reset environment variables, set a new home directory, reset some aliases, use a different PATH (Section 35.6), whatever. When you end the subshell, the parent shell's environment will be the way it was.
If your parent shell has job control (Section 23.3), you can stop the subshell and pop back to your parent shell without losing the changes in the subshell. If the child shell has job control, too, the command suspend (or kill -STOP $$ (Section 27.17)) will stop it. Otherwise, just type CTRL-z at the subshell's prompt. For example:
prompt Section 4.1
myprompt% csh myprompt% set prompt="project% " project% cd project-directory project% setenv PRINTER plotter project% set path=($path some-new-directories) project% setenv EXINIT "se ts=4 sw=4 aw wm=0" ...do some work... project% suspend Stopped ...back to parent shell... myprompt% myprompt% fg %csh ...back to subshell... project%
I use suspend so much that I've made a CTRL-z-like alias named z:
alias z suspend ...csh alias z=suspend ...bash, ksh
If you need a different type of shell temporarily, just type that shell's name at a prompt. When you end the shell by typing exit or by suspending it (as shown above), you're back to your usual shell. For example, you might normally use bash but want to use the zsh multiline editing for a few loops you need to run. As another example, I started a lot of different shells while I was writing this book and suspended them, as above, when I wasn't using them. Very handy.
A shell escape (Section 17.21) starts a subshell. Do whatever you want to the subshell's environment. When you end the shell escape, the changes go away.
The su command starts a subshell. cd anywhere, change environment variables, and so on.
If you use the exit command, a subshell (or any shell) will terminate. In a script, when the shell reads the end of file, that does an implicit exit. On the command line, an end-of-input character (usually CTRL-d) will do the same thing. Section 35.16 explains how exit sets a shell's exit status.
JP
The ps command varies from system to system. (The ps on one Red Hat Linux system reads a PS_PERSONALITY environment variable with 21 possible settings!) This article describes several different versions. Yours is probably different in some ways, so check your ps manual page for details.
The ps command produces a report summarizing execution statistics for current processes. The bare ps command lists the process ID, the terminal from which the command was started, how much CPU time it has used, and the command itself. The output looks something like this (it differs by system):
PID TT STAT TIME COMMAND 1803 p5 IW 0:00 -csh (csh) 1883 p5 IW 0:04 vi outline 1811 p6 IW 0:01 -csh (csh) 5353 p6 TW 0:01 vi 4890
By default, ps lists only your own processes. There are many times, though, when it's desirable to have a more complete listing with a lot of data about all of the processes currently running on the system. The options required to do this differ between BSD Unix and System V. Under BSD Unix, the command is ps -aux, which produces a table of all processes, arranged in order of decreasing CPU usage at the moment when the ps command was executed. [The -a option gives processes belonging to all users, -u gives a more detailed listing, and -x includes processes that no longer have a controlling terminal (Section 24.6). TOR] It is often useful to pipe this output to head (Section 12.12), which will display the most active processes:
% ps -aux | head -5 USER PID %CPU %MEM SZ RSS TTY STAT TIME COMMAND martin 12923 74.2 22.5 223 376 p5 R 2:12 f77 -o foo foo.F chavez 16725 10.9 50.8 1146 1826 p6 R N 56:04 g94 HgO.dat ng 17026 3.5 1.2 354 240 co I 0:19 vi benzene.txt gull 7997 0.2 0.3 142 46 p3 S 0:04 csh
The meanings of the fields in this output (as well as others displayed by the -l option to ps) are given in Table 24-1.
The first line of this output shows that user martin is running a FORTRAN compilation (f77). This process has PID (Section 24.3) 12923 and is currently either running or runnable. User chavez's process (PID 16725), executing the program g94, is also running or runnable, though at a lowered priority. From this display, it's obvious who is using most system resources at this instant: martin and chavez have about 85% of the CPU and 73% of the memory between them. However, although it does display total CPU time, ps does not average the %CPU or %MEM values over time in any way.
|
Column[3] |
Contents |
|---|---|
|
USER (BSD) |
Username of process owner |
|
UID (System V) |
User ID (Section 24.3) of process owner |
|
PID |
Process ID |
|
%CPU |
Estimated fraction of CPU consumed (BSD) |
|
%MEM |
Estimated fraction of system memory consumed (BSD) |
|
SZ |
Virtual memory used in K (BSD) or pages (System V) |
|
RSS |
Real memory used (in same units as SZ) |
|
TT, TTY |
Terminal port associated with process |
|
STAT (BSD), S (System V) |
Current process state; one (or more under BSD) of: |
|
R: Running or runnable |
|
|
S: Sleeping |
|
|
I: Idle (BSD); intermediate state (System V) |
|
|
T: Stopped (Section 23.1) |
|
|
Z: Zombie process (Section 24.19) |
|
|
D (BSD): Disk wait |
|
|
P (BSD): Page wait |
|
|
X (System V): Growing,waiting for memory |
|
|
K (AIX): Available kernel process |
|
|
W (BSD): Swapped out |
|
|
N (BSD): Niced (Section 26.5, Section 26.7), execution priority lowered |
|
|
> (BSD): Execution priority artificially raised (Section 26.7) |
|
|
TIME |
Total CPU time used |
|
COMMAND |
Command line being executed (may be truncated) |
|
STIME (System V) |
Time or date process started |
|
C (System V), CP (BSD) |
Short term CPU-use factor; used by scheduler for computing execution priority (PRI below) |
|
F |
Flags associated with process (see ps manual page) |
|
PPID |
Parent's PID |
|
PRI |
Actual execution priority (recomputed dynamically) |
|
NI |
Process nice number (Section 26.5) |
|
WCHAN |
Event process is waiting for |
A vaguely similar listing is produced by the System V ps -ef command:
$ ps -ef UID PID PPID C STIME TTY TIME CMD root 0 0 0 09:36:35 ? 0:00 sched root 1 0 0 09:36:35 ? 0:02 /etc/init ... gull 7997 1 10 09:49:32 ttyp3 0:04 csh martin 12923 11324 9 10:19:49 ttyp5 56:12 f77 -o foo foo.F chavez 16725 16652 15 17:02:43 ttyp6 10:04 g94 HgO.dat ng 17026 17012 14 17:23:12 console 0:19 vi benzene.txt
The columns hold the username, process ID, parent's PID (the PID of the process that created it), the current scheduler value, the time the process started, its associated terminal, its accumulated CPU time, and the command it is running. Note that the ordering is by PID, not resource usage.
AIX's version of the ps command supports both BSD and System V options. The BSD options are not preceded by a hyphen (which is a legal syntax variation), and the System V options are. Thus, under AIX, ps -au is not the same as ps au. The command is the System V version, however, even if its output is displayed with the BSD column headings. Thus, ps aux output is displayed in PID rather than %CPU order.
ps is also useful in pipes; a common use is:
% ps -aux | grep chavez
to see what user chavez has currently running. Under System V, use ps -u chavez.
Another way to view the process information is with the top command. Unlike ps, top is an interactive screen program that updates its information every few seconds. It's a good way to get a quick pulse of your system. Not only is process information displayed, but memory statistics and the system uptime are also shown. You can find the full range of available interactive commands by typing h once top has started. You can sort processes in a variety of ways including CPU and memory usage, as well as by user. You can even kill processes from within top.
AF, from Essential System Administration (O'Reilly, 2002), and JJ
In Section 24.5, we pointed out that the ps command needs special options (-x for BSD-derived versions and -e for System V-type) to list processes without a controlling terminal.
But just what is a controlling terminal? Just what it sounds like: the terminal from which the process was started. In the ps listing, this is usually given as a tty, or terminal ID. That ps entry usually corresponds to a serial port, or a pty. A pty or "pseudo-terminal" is a construct that makes a window or network login (Section 1.21) look to the operating system just like a terminal.
In the ps listing, a tty might appear as t1 for /dev/tty1, p3 for /dev/ttyp3, or as some other designation, such as co for /dev/console, the full-screen display of a workstation before any window system is started. Processes without a controlling terminal show a question mark (?).
How does a process "lose" its controlling terminal? Easy. Some processes, such as system "daemons" (Section 1.10) never had one they were started by system scripts that weren't started from any terminal, or they disconnected themselves from their controlling terminals. But it's also possible that you started a process running in the background, logged out, and logged back on later or on another terminal to find it still running without a controlling terminal. Disowned processes (Section 23.11) fit this category too.
The tty command can be used to report which "terminal" you're currently connected to. For example:
% tty /dev/ttyp2
Running tty without a controlling terminal gives the message not a tty.
TOR
ps without arguments lists all processes started from the current terminal or pseudo-terminal. But since ps is not a shell command, it doesn't correlate process IDs with the shell's job numbers. It also doesn't help you find the ID of the runaway process in another shell window.
To get this information, use ps -a (for "all"); this lists information on a different set of processes, depending on your Unix version.
Instead of listing all that were started under a specific terminal, ps -a on System V-derived systems lists all processes associated with any terminal that aren't group leaders. For our purposes, a "group leader" is the parent shell of a terminal or window. Therefore, if you are using a windowing system, ps -a lists all jobs started in all windows (by all users), but not their parent shells.
Assume that, in the previous example, you have only one terminal or window. Then ps -a will print the same output as plain ps except for the first line, since that's the parent shell. This doesn't seem to be very useful.
But consider what happens when you have multiple windows open. Let's say you have three windows, all running terminal emulators such as xterm for the X Window System. You start background jobs alice, duchess, and hatter in windows with pseudo-terminal numbers 1, 2, and 3, respectively. This situation is shown in Figure 24-1.
Assume you are in the uppermost window.  If it's hatter, you can type kill 2389.
On BSD-derived systems, ps -a lists all jobs that were started on any terminal; in other words, it's a bit like concatenating the the results of plain ps for every user on the system. Given the above scenario, ps -a will show you all processes that the System V version shows, plus the group leaders (parent shells).
Unfortunately, ps -a (on any version of Unix) will not report processes that are in certain conditions where they "forget" things such as what shell invoked them and what terminal they belong to. Such processes are known as zombies or orphans (Section 24.19). If you have a serious runaway process problem, it's possible that the process has entered one of these states.
You need another option to ps to see it: on System V, it's ps -e ("everything"); on BSD, it's ps -ax.
These options tell ps to list processes that either weren't started from terminals or "forgot" what terminal they were started from. The former category includes lots of basic processes that run the system and daemons (Section 1.10) that handle system services like mail, printing, network file systems, etc.
In fact, the output of ps -e or ps -ax is an excellent source of education about Unix system internals. Run the command on your system and, for each line of the listing that looks interesting, invoke man (Section 2.1) or info (Section 2.9) on the process name.
User shells and processes are listed at the very bottom of ps -e or ps -ax output; this is where you should look for runaway processes. Notice that many processes in the listing have ? instead of a terminal. Either these aren't supposed to have a terminal (such as the basic daemons), or they're runaways. Therefore it's likely that if ps -a doesn't find a process you're trying to kill, ps -e or ps -ax will list it with ? in the TTY (or TT) column. You can determine which process you want by looking at the COMD (or COMMAND) column.
Section 24.22 shows a similar thing: how to close windows by killing their process.
CN and BR
There is a reason that some versions of ps, and thus derivatives such as w, sometimes print commands in parentheses:
% ps -f -u jerry UID PID PPID C STIME TTY TIME COMMAND jerry 29240 29235 0 07:56:19 ttyp1 0:01 sh find_mh_dupes jerry 29259 29240 23 07:57:52 ttyp1 0:07 (egrep)
The reason is that whoever wrote ps liked it that way. The parentheses indicate that the command overwrote its name, or ps could not find the name, and that ps is printing instead the "accounting name." (The accounting name is the last component of the name given to the exec (Section 24.2) system call, and is the name used in the system resource usage accounting file.) Basically, ps does this in the C language:
if (proc->argv == NULL || strcmp(proc->acct_name, proc->argv[0]) != 0) printf("(%s)", proc->acct_name);
In the case of a large environment, ps is unable to find the argument vector. This is because it reads only the last few stack pages of each process.
Other versions of ps use completely different mechanisms for locating the command arguments and may never print parentheses.
CT, in net.unix-wizards on Usenet, 13 November 1983
In Unix, it seems almost everything can be treated like a file (Section 1.19). On many modern Unix systems, even processes are files well, sort of. A special filesystem named /proc doesn't actually "contain" processes, but it lets you interact with them. Almost all of the "files" in /proc are plain text, so you can access them from scripts and programs, as well as from the command line. Of the systems I've checked, my Red Hat Linux 6.2 box (kernel version 2.2) seems to have the most in /proc, so I'll cover it. Please check your documentation a proc(5) manual page, for instance for the story on your system.
All /proc filesystems have one subdirectory for each process currently running on the system. Each of those process subdirectories is named for its PID (Section 24.3). Some versions of /proc also have other named files and subdirectories and my system has a lot of them. Here's a partial listing of my /proc filesystem at the moment; I've left out a lot of the numbered subdirectories:
-F Section 8.10
$ ls -F /proc 1/ 17415/ 467/ cmdline ksyms pci 1047/ 2/ 482/ cpuinfo loadavg rtc 1052/ 3/ 5/ devices locks scsi/ 1057/ 345/ 553/ dma mdstat self@ 1287/ 370/ 593/ fb meminfo slabinfo 1289/ 379/ 594/ filesystems misc stat 14288/ 393/ 595/ fs/ modules swaps 14289/ 4/ 596/ ide/ mounts sys/ 17409/ 4017/ 597/ interrupts mtrr tty/ 17412/ 407/ 6/ ioports net/ uptime 17413/ 425/ apm kcore partitions version 17414/ 439/ bus/ kmsg
Linux system utilities like ps and pidof use information from /proc. Your programs can use it, too; there are some examples below. But it's also useful when you want to know something about your system. The "files" in /proc are most useful there. Let's look at a series of examples. We'll end with the numbered per-process "directories."
The Linux free(1) utility shows your memory status. It simply reads the file /proc/meminfo and reformats the information. If you want an alias (Section 29.2) that simply shows how much memory is free, it's probably simpler to read the meminfo file directly. For example:
grep Section 13.1
$ cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 263929856 253022208 10907648 79675392 30797824 57868288 Swap: 394784768 14585856 380198912 MemTotal: 257744 kB MemFree: 10652 kB MemShared: 77808 kB Buffers: 30076 kB Cached: 56512 kB BigTotal: 0 kB BigFree: 0 kB SwapTotal: 385532 kB SwapFree: 371288 kB $ alias memfree='grep Free: /proc/meminfo' $ memfree MemFree: 10616 kB BigFree: 0 kB SwapFree: 371288 kB
(The free RAM decreased a bit while I was writing the alias.)
The /proc/stat file has statistics on the kernel and system. As with most of the rest of /proc, it's updated constantly. For example, we can grep for the CPU statistics. The four fields on the cpu line show the number of jiffies (hundredths of a second) since the system was last rebooted: time spent in normal-priority user mode, niced user mode (Section 26.5), system (kernel) mode, and the idle task, respectively. You might want to use this information from a script that monitors your system's utilization. Here's an example: grepping for the CPU ststistics, then the start of an awk (Section 20.10) script that could watch the CPU usage:
!! Section 30.8
$ grep cpu /proc/stat cpu 14693561 48135949<PHONE_NUMBER>301 $ awk '/^cpu/ { print $5 / 100 " seconds idle" }' /proc/stat 40318.7 seconds idle $ !! awk '/^cpu/ { print $5 / 100 " seconds idle" }' /proc/stat 40323.8 seconds idle
The sections below describe per-process subdirectories in /proc. One special directory is /proc/self. It has the unusual property of giving a different answer for every process that examines it: information about the current process. (This "directory" is actually a symbolic link (Section 10.4) to the directory numbered for the process' PID.)
For instance, a process can check its /proc/self/fd directory to see which files its file descriptors (Section 36.15) are currently pointing to. This isn't just what type of file (disk file, tty (Section 2.7), pipe, etc.) but the actual full pathname of the file. If you're new to Unix, this may not seem too earth-shaking, but it's actually pretty amazing.
For a simple example, here's a shell script that lists its input and outputs. It then redirects its standard input (file descriptor 0) from /dev/null (Section 43.12) and lists again.
$ pwd /tmp $ tty /dev/pts/5 $ cat showfds #!/bin/sh cd /proc/self/fd ls -l exec 0</dev/null ls -l $ ./showfds < somefile total 0 lr-x------ 1 jpeek jpeek 64 Dec 2 09:03 0 -> /tmp/somefile lrwx------ 1 jpeek jpeek 64 Dec 2 09:03 1 -> /dev/pts/5 lrwx------ 1 jpeek jpeek 64 Dec 2 09:03 2 -> /dev/pts/5 lr-x------ 1 jpeek jpeek 64 Dec 2 09:03 3 -> /tmp/showfds total 0 lr-x------ 1 jpeek jpeek 64 Dec 2 09:03 0 -> /dev/null lrwx------ 1 jpeek jpeek 64 Dec 2 09:03 1 -> /dev/pts/5 lrwx------ 1 jpeek jpeek 64 Dec 2 09:03 2 -> /dev/pts/5 lr-x------ 1 jpeek jpeek 64 Dec 2 09:03 3 -> /tmp/showfds
All versions of /proc that I've seen have subdirectories named for each process currently running on the system. Each subdirectory is named for the process PID (Section 24.3). Here are a series of examples of the useful info on my Linux system:
Go to http://examples.oreilly.com/upt3 for more information on: showenv
You can use printenv or env (Section 35.3) to find the environment of your current process. How about the environment of another process? Here's a shell script called showenv that works like printenv:
#!/bin/sh # showenv - show environment of a process, by PID # If second argument given, show just that one environment variable. f=/proc/$1/environ if [ ! -r "$f" ]; then echo "`basename $0`: can't access process $1" 1>&2 exit 1 fi case $# in 1) tr '\000' '\012' < $f | sort ;; 2) tr '\000' '\012' < $f | grep "^$2=" ;; *) echo "Usage: `basename $0` pid [envariable-name]" 1>&2; exit 1 ;; esac
The tr (Section 21.11) command translates the NUL-separated entries from the environ file into newline-separated lines. With one argument, the whole environment is shown. With two arguments, the script greps for the environment variable named in the second argument. Maybe you'd like to know what the EXINIT (Section 17.27) environment variable was set to in a vi process with PID 8984:
$ showenv 8984 DISPLAY=:0.0 ECIINI=/usr/lib/ViaVoiceTTS/eci.ini EDITOR=vi EXINIT=so ~/.lib/vi/exrc8 HISTFILESIZE=1000 ... $ showenv 8984 EXINIT EXINIT=so ~/.lib/vi/exrc8
The status file gives status information about the process. A lot of this information is available in ps (Section 24.5) output, but it's broken out nicely here. For instance, maybe you're wondering what group access process 918 has, or what process started it (its parent PID (Section 24.3)):
% cd /proc/918 % grep PPid status PPid: 916 % grep Groups status Groups: 1000 501 103
The PPID is 916. The process has the group numbers (can access resources with the group permissions of) GIDs 1000, 501, and 103.
The command-line arguments of a process are in the cmdline file, separated by NUL characters. Hmmm, what files is that tail -f job, process 861, watching? Let's see...using echo (Section 27.5) to add a final newline:
$ tr '\000' ' ' < /proc/861/cmdline; echo tail -f /var/log/messages /var/log/maillog /u/jerry/tmp/startx.log
If you are curious about your system's hardware, a quick look at /proc/cpuinfo, /proc/interrupts, and /proc/ioports will help you size up the system. All the following examples came from a Red Hat Linux box, but you will find these proc files on most Linux and BSD systems. For instance, /proc/cpuinfo looks like this (on my system):
processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 6 model name: Celeron (Mendocino) stepping: 0 cpu MHz: 400.918 cache size: 128 KB fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 2 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 sep mtrr pat pse36 mmx fxsr bogomips: 799.53
The most important fields to notice are processor, model name, and cpu MHz since these identify how many CPUs are in the system, the model name (although this isn't always so clear in older Pentium models), and the CPU speed of your machine.
The other three proc files are important if you are installing hardware or trying to configuring recently installed hardware. /proc/interrupts lists the hardware interrupt numbers and shows which devices are using which interrupt. On my machine, this looks like:
CPU0 0: 92887036 XT-PIC timer 1: 910141 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 4 XT-PIC serial 5: 4794267 XT-PIC eth0 8: 11642728 XT-PIC rtc 10: 65248789 XT-PIC es1371 11: 0 XT-PIC usb-uhci 12: 5109157 XT-PIC PS/2 Mouse 14: 560048 XT-PIC ide0 15: 408739 XT-PIC ide1 NMI: 0 ERR: 0
/proc/ioports lists the hardware I/O port ranges that all your systems devices use. This is a good file to examine if recently installed hardware can't be found in your drivers. Here's an abbreviated sample of my system's /proc/ioports.
03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 4000-403f : Intel Corporation 82371AB PIIX4 ACPI 5000-501f : Intel Corporation 82371AB PIIX4 ACPI c000-cfff : PCI Bus #01 d000-d01f : Intel Corporation 82371AB PIIX4 USB d400-d43f : Ensoniq ES1371 [AudioPCI-97] d800-d807 : Lucent Microelectronics 56k WinModem dc00-dcff : Lucent Microelectronics 56k WinModem e000-e0ff : PCI device 1186:1300 (D-Link System Inc) f000-f00f : Intel Corporation 82371AB PIIX4 IDE
This file makes it easy to diagnosis hardware conflicts. However, if your system is working well, you probably won't be looking at any of these files much.
JP
Signals are a simple but important means of interprocess communication. Interprocess communication sounds fancy, but it's really a simple concept: it's the means by which one program sends a message to another program. It's common to think of signals as special messages sent by the Unix kernel (Section 1.10) but, in fact, any program can signal any other program.
What kinds of messages can you send with a signal? Relatively few, in reality. Signals aren't "arbitrary" messages, like letters; they are a small group of pre-defined messages, each with its own special meaning. System V Unix supports 16 signals, each of which is assigned a number; BSD-derived Unix implementations and SVR4 have 32 signals. Table 24-2 lists some of the more commonly used signals. It also lists keyboard characters that send common signals on BSD systems (these can be changed; see Section 5.8).
|
Signal name |
Number |
Meaning and typical use |
|---|---|---|
|
HUP |
1 |
Hangup stop running. Sent when you log out or disconnect a modem. |
|
INT |
2 |
Interrupt stop running. Sent when you type CTRL-c. |
|
QUIT |
3 |
Quit stop running (and dump core). Sent when you type CTRL-\. |
|
KILL |
9 |
Kill stop unconditionally and immediately; a good "emergency kill." |
|
SEGV |
11 |
Segmentation violation you have tried to access illegal memory. |
|
TERM |
15 |
Terminate terminate gracefully, if possible. |
|
STOP |
17* |
Stop unconditionally and immediately; continue with CONT. |
|
TSTP |
18* |
Stop stop executing, ready to continue (in either background or foreground). Sent when you type CTRL-z. stty (Section 5.8) calls this susp. |
|
CONT |
19* |
Continue continue executing after STOP or TSTP. |
|
CHLD |
20* |
Child a child process's status has changed. |
Note that signal numbers especially the ones above 15, marked with an asterisk in Table 24-2 vary system-to-system. Use the signal name wherever you can.
While the list in Table 24-2 isn't definitive, it shows you the types of things signals can do. Many signals, like SIGSEGV, are warning or error messages. You've probably seen the frustrating "segmentation violation" message. That message came when the kernel detected something wrong and sent your program a SIGSEGV signal; in response, your program quit. Others signals, like SIGTSTP, are generated in response to special characters on the keyboard. And a lot of signals just say, "Your time is up, goodbye!"
When a process receives a signal, it can take a number of actions; for example:
It can take whatever default action is specified for the signal. By default, some signals kill the process that receives them. For some signals, the default action is to stop running and dump core. (SIGQUIT is an example of this.) Other signals have no effect by default.
It can trap (Section 35.17) the signal and run a special "signal handling" function in which case, it can do whatever it wants. A signal handler often does whatever's necessary to shut the program down nicely: make sure that files are closed and left in a consistent state, and so on.
It can ignore the signal, in which case nothing happens.
 Why?
 As you now know, signals often bring death and destruction, but there's no necessary reason for them to do so.
ML
You probably know that typing CTRL-c (Section 24.10) will terminate your foreground job. But what actually happens when you type CTRL-c?
When you type CTRL-c, you're sending the INT (interrupt) signal (Section 24.10) to the foreground process. Most well-designed programs "catch" the interrupt signal, which means that the program installs some special function (a "signal handler") that is called whenever a signal arrives. The signal handler normally closes all open files, resets your terminal properly (if needed), and does anything else necessary so that the program can depart from this world in peace. Then the program terminates. The QUIT signal, sent by CTRL-\, works similarly but also makes a core file for debugging.
Of course, it's possible for the signal handler to do something else entirely: the program can decide not to quit, or it can implement some truly bizarre feature. In fact, editors such as vi or Emacs almost always ignore most signals. The trap ( Section 35.17) command handles signals in the Bourne shell.
Whenever you send a signal from the keyboard, it's sent to all processes in the same process group (Section 24.3). This may include the program's child processes, but it may not.  But more often than not, killing the parent process kills its children.
Section 5.8 explains how to set the key that sends these and other signals. The kill (Section 24.12) command also sends signals.
ML and JP
Sometimes it's necessary to eliminate a process entirely or to signal a process (Section 24.13); this is the purpose of the kill command. You can use the kill command with or without a signal id:
% kill pid % kill -signal pid
where pid is the process' identification number, and signal (which is optional) is the signal to send to the process. The default signal is number 15, the TERM signal, which tells the process to terminate. On some systems, the signal must be specified numerically; others allow you to use either the signal number or its symbolic name. [Use kill -l for a list of signal names; unfortunately, the listing doesn't show the correspondence of names and numbers. However, they are in order, so if you can count, you can figure it out. TOR]
Sometimes, a process may still exist after a kill command. If this happens, execute the kill command with the -KILL or -9 option. This almost always guarantees that the process will be destroyed. However, it does not allow the dying process to clean up, and therefore may leave the process' files in an inconsistent state.
 The vast majority of such processes fall into one of three categories:
Zombies. A process in the zombie state (Section 24.19) is displayed as Z status in BSD ps (Section 24.5) displays and as <defunct> under System V. When a process is exiting, it informs its parent of its imminent death; when it receives an acknowledgment, its PID is removed from the process table. A zombie process is one whose total resources have been freed, but whose parent process' acknowledgment has not occurred. Usually, init will step in when the parent is gone, but very occasionally this fails to happen. Zombies are always cleared the next time the system is booted and do not adversely affect system performance.
Processes waiting for unavailable NFS (Section 1.21) resources (for example, trying to write to a remote file on a system that has crashed) will not die if sent a KILL signal. Use the QUIT signal (3) or the INT (interrupt) signal (2) to kill such processes.
Processes waiting for a device to complete an operation before exiting. Often this means waiting for a tape to finish rewinding.
Killing a process may also kill all of its children. Child processes may not die if they're blocking or "catching" the signal you use although, as explained above, the KILL signal (9) will usually terminate those processes. Killing a shell can therefore kill all the foreground and stopped background processes initiated from that shell (including other shells). Killing a user's login shell is equivalent to logging the user out. This is a useful (if somewhat painful) way to recover from certain kinds of problems. For example, if a user manages to confuse his editor by mistyping control keys and escape sequences, or enters an infinite loop that he can't terminate by normal means, killing his shell will let him regain control of the situation, possibly at the cost of some work. Use the ps command to determine which process is the offending user's shell. Remember that you must be superuser (Section 1.18) to kill someone else's process.
If you're using the X Window System, Section 24.20 shows how to find which window has the processes you may need to kill.
AF, from Essential System Adminstration (O'Reilly, 2002)
[This article may not appear to have a lot to do with the subject of this chapter, but it illustrates the other side of signal handling what a program or shell script can do when it receives a signal. Jerry's script uses the trap (Section 35.17) command to catch several different signals and act differently depending on whether the signal is a "hangup" (HUP , or signal 1) or a TERM (signal 15). TOR]
Unix systems run "daemon" programs such as cron(8) and syslogd(8) that wait in the background, looking for work to do. Many daemons read configuration files when they start up. System administrators sometimes change the configuration files and want the daemon to reread the file. One way to do that is by terminating and restarting the program but that's ugly and also means the daemon won't be running for a few seconds until it's restarted. So many daemons are designed to reread their configuration files and/or restart themselves when they get a signal (usually the HUP signal, signal 1). System administrators do this by getting the daemon's process ID number and sending the signal with the kill command. Because the daemon "catches" the signal, the daemon isn't actually killed.
You can run a shell script as a daemon by putting it in the background.[4] Here's a simple example, a shell script named watchq. It reads a file full of printer queue names and stores it in a shell variable. Every 30 seconds, it runs lpq (Section 45.2) on all printer queues listed. If any queues have an error, the script echoes a message and the output of lpq to a particular user with the write (Section 1.21) command. (You could change it to write to the system's syslog by calling logger(1) instead of write. Or use xmessage (Section 36.26) to pop a notice window onto someone's X Window System console. Etc., etc.)
The script uses numbers (0, 1, 15) instead of signal names (EXIT, HUP, TERM). This is for portability to older Unix shells that don't understand names in trap commands. But if you write a script like this on a newer system, use signal names if you can.
Go to http://examples.oreilly.com/upt3 for more information on: watchq
/dev/null Section 43.12
#! /bin/sh # watchq - "daemon" script that watches printer queue(s) for errors temp=/tmp/WATCHQ$$ # Holds output of lpq watch=/usr/local/lib/watchqs # Queue names to watch writeto=lisa # User who gets notices about printer queues="`cat $watch`" # Put list of queue names in $queues trap 'queues="`cat $watch`"' 1 # Reset $queues if we get a SIGHUP trap 'rm -f $temp; exit' 0 15 # Clean up temp file when killed # Loop forever (until someone kills script): while : do for queue in $queues do lpq -P$queue >$temp if egrep '(out of paper|error|warning)' $temp >/dev/null then echo "PRINTER QUEUE $queue:" | cat - $temp | write $writeto fi done sleep 30 done
Now let's run the script. After the script has run for a while, the printer named office goes down. I edit the watchqs file and remove that printer so the poor user lisa won't keep getting complaints about it. Then I send a signal to have the file reread:
kill Section 24.12
% echo office main lobby > /usr/local/lib/watchqs % watchq & [1] 4363 ... % echo main lobby > /usr/local/lib/watchqs % kill -HUP 4363 ... % kill 4363 [1] Exit -48 watchq
In real life, the watchq script might be started from a system file like /etc/rc.local when the system reboots. Lisa would probably edit the watchqs file herself. The username that's notified by write might also be resettable with a kill -HUP (or kill -1).
This isn't foolproof, and you can run into subtle problems. For instance, the write command may not work on some Unixes if it's running from a daemon without a controlling tty (Section 24.6). Also, the error messages that egrep (Section 13.4) searches for may not catch all problems, and they are system-dependent. If you use xmessage, a user who's away from his workstation could come back to tens or hundreds of windows; you might want to make the script pause until the user acknowledges a window. But this script is just a demonstration to show a great way to write a quick-and-dirty daemon.
JP
On many Unix systems, kill (Section 24.12) interprets the special "process ID" -1 as a command to signal all your processes (all processes with your user ID), except for the process sending the signal. For example, the following command will terminate all your processes:[5]
% kill -TERM -1
To see if your system supports this feature, type man 2 kill (Section 2.1) to read the kill(2) manual page.

This command is also useful in desperate situations. If processes are spawning out of control, or if your terminal is locked, you can log in from another terminal and kill everything, without having to dig through ps (Section 24.5) to find the right process. The zap (Section 24.16) script searches process lists and kills processes automatically.
The special -1 process ID is defined differently for the superuser; if you're root, it means "all processes except system processes."
If you can't use the -1 process ID, and you use the Bourne shell or another shell without job control, you can use a 0 (zero) process ID. That sends the signal to all members of the process group (that is, processes resulting from the current login). A 0 doesn't work on shells, such as the C shell, that have job control (Section 23.3).
ML, JP, and JIK
This article discusses a particular version of kill that has some problems. Your system may have a different kill and, possibly, a version of killall (Section 24.16) that doesn't seem to have as many problems. But this article is worth reading anyway for what it shows you about process names and the ps command. It's good info to keep in mind when you're trying to kill processes in a hurry.
On my Linux system, the kill(1) manual page says I can send signals to processes either by PID numbers (as we showed in Section 24.12) or by process names. To an old stick-in-the-mud Unix user like me, who's been killing processes by their PIDs for 20 years, this doesn't seem very appealing. But hey, even I appreciate some of the new things Unix and Linux can do! ;-) So we're saying that, if my system is slow and I want to temporarily stop the two gcc compiles I'm running in the background, I can just type:
$ kill -STOP gcc [2] Stopped gcc -c bigprog.c sub1.c sub2.c ... [4]- Stopped gcc -o something something.c
Not necessarily. This is not always as simple as it seems. For one, before you kill a process by name, you'd better be sure that there are no other processes by that name, owned by you, running at the same time unless you want to kill them too. That includes processes on other windows and ttys you're logged onto at the time; it also includes at, cron, or batch jobs that are running somewhere else on the system. Second, the process name may not be what you think it is.
For example, let's say I have a runaway shell script named cruncher. I'm running it twice, and I want to kill both instances.  In command 2, I try to kill them by name. But my shell, bash2, is complaining "no such pid." Hmmm; it's using the shell's built-in kill; the bash2 manpage seems to say that its kill only understands PID numbers. So, in command 3, I run type -all and find that the system kill is /bin/kill. In command 4, I give the process name again, but /bin/kill can't find it. Say what? Typing jobs, command 5, shows two crunchers running. And I can kill one of them by using its job number, in command 6. More confusing, running ps, in command 7, also shows cruncher running.
The story ends at command 8, where I ran the BSD version of ps (Section 24.5). It shows me what the default "friendly" System V-style ps (in command 7) didn't: the complete command line is actually sh /u/jerry/.bin/cruncher. This is a shell script, so the script filename cruncher, with the executable's directory from the PATH (Section 35.6) prepended, is passed to a shell as an argument (Section 27.3).  But do I really want to kill all running shells?
Another problem with killing a process by name is that a process can start a subprocess (Section 24.3) with a different name.  Maybe if the signal that make gets is passed to its subprocesses (if its subprocesses haven't been disowned (Section 23.11), for instance).

My advice? It might be easier to use the old way running ps to find the process(es) and kill by PID number or use a script like zap (Section 24.16) instead.
JP
When you want to kill processes, it's a pain in the neck to run ps (Section 24.5), figure out the process ID, and then kill the process although sometimes you have to do it that way (Section 24.15). We'll look at two easier ways.
Many systems have a command named killall with a -i ("interactive") option. Be careful, though, because there are several versions, and the most basic does just what it says: kills all processes on the system (when run as the superuser (Section 1.18)). Check killall's manual page on your system.
The version of killall we're talking about here accepts multiple process-name arguments on its command line. Without its -i option, the command sends a signal (by default, TERM) to any process name that matches. The process name you give has to match completely.   The script uses egrep (Section 13.4) to pick the processes to kill; you can type extended expressions (Section 32.15) that match more than one process. The expressions can match partial or complete command names, any arguments to the commands, or, actually, any part of the command's line in the ps output. For example:
% zap 'troff|fmat' PID TTY TIME CMD 22117 01 0:02 fmat somefile? n 22126 01 0:15 sqtroff -ms somefile? y
We reprint the script by permission of the authors:
Go to http://examples.oreilly.com/upt3 for more information on: zap
'...'  Leave off the a to get just your processes. Your version of ps may need different options (Section 24.5).
This shell version of zap calls another script, pick, shown below.[6] pick shows each of its command-line arguments and waits for you to type y, q, or anything else. Answering y writes the line to standard output, answering q aborts pick without showing more lines, and any other answer shows the next input line without printing the current one. zap uses awk (Section 20.10) to print the first argument (the process ID number) from any ps line you've selected with pick. The inner set of nested (Section 36.24) backquotes (Section 28.14) in zap pass pick the output of ps, filtered through egrep. Because the zap script has set the IFS variable (Section 36.23) to just a newline, pick gets and displays each line of ps output as a single argument. The outer set of backquotes passes kill (Section 24.12) the output of pick, filtered through awk.
If you're interested in shell programming and that explanation wasn't detailed enough, take a careful look at the scripts they're really worth studying. (This book's shell programming chapters, 44 through 46, may help, too.) Here's the pick script:
Go to http://examples.oreilly.com/upt3 for more information on: pick
/dev/tty Section 36.15
#!/bin/sh # pick: select arguments PATH=/bin:/usr/bin for i do echo -n "$i? " >/dev/tty read response case $response in y*) echo $i ;; q*) break esac done </dev/tty
JP
Especially if you're a programmer, you can run into a situation where you have processes forking (Section 24.2) out of control more and more of them.

Stop any process you can so that it can't fork more processes. Stop them all. Then start cleaning up with kill -9.
If your system manager has set a per-user process limit on your computer, the good news is that your processes won't eventually crash the system. But the bad news is, when you try to run any command that isn't built into the shell (Section 1.9) (like killall (Section 24.16), which would be nice to use in this situation, if you have it):
% killall -STOP myprog No more processes.
you can't because you're already at your limit.
If that happens, log on to another account or ask someone to run a command that will give a list of your processes. Depending on your system, the command is probably like one of these two:
% ps -u yourname System V % ps aux | grep yourname BSD
Then go back to your terminal and start stopping :-). If you get the No more processes error, your shell must not have a built-in kill command. Many shells do including bash and csh. Carefully type the next commands to be sure that /bin/bash exists (assuming your shell has a built-in echo, this trick[7] bypasses the external ls command); then, if the shell is there, replace your shell with bash. Don't make a mistake (if you do, you may not be able to log in again):
exec Section 36.5
$ echo /bin/bas? /bin/bash $ exec /bin/bash bash$ kill ...
JP
You or another user might have a process that (according to ps (Section 24.5)) has been sleeping for several days, waiting for input.
These processes can be unkillable because they've made a request for a hardware device or network resource. Unix has put them to sleep at a very high priority and the event that they are waiting on hasn't happened (because of a network problem, for example). This causes all other signals to be held until the hardware event occurs. The signal sent by kill doesn't do any good.
If the problem is with a terminal and you can get to the back of the terminal or the back of the computer, try unplugging the line from the port. Also, try typing CTRL-q on the keyboard if the user typed CTRL-s while getting a lot of output, this may free the process.
Ask your vendor if there's a special command to reset the device driver. If there isn't, you may have to reboot the computer.
JP
Processes in your ps output that are in the <exiting> or Z status are called zombies.

"What is a zombie?" I hear you ask.
Dead processes stick around for two principal reasons. The lesser of these is that they provide a sort of "context" for closing open file descriptors (Section 24.3) and shutting down other resources (memory, swap space, and so forth). This generally happens immediately, and the process remains only for its major purpose: to hold on to its name and exit status (Section 35.12).
A process is named by its process ID or PID. Each process also has associated with it a parent process ID. The parent PID, or PPID, is the PID of the process that created it via fork (Section 24.2); if that particular process has since vanished, the parent PID is 1 (the PID of init (Section 24.2)). While the original parent is around, it can remember the PIDs of its children. These PIDs cannot be reused until the parent knows the children are done. The parent can also get a single byte of status (Section 35.12) from each child. The wait system call looks for a zombie child, then "collects" it, making its PID available and returning that status. The init(8) program is always waiting, so that once a parent exits, init will collect all its children as they exit and promptly ignore each status.
So, to get rid of a zombie, you must wait for it. If you have already done so or if the process' PPID is 1, the process is almost certainly stuck in a device driver close routine, and if it remains that way forever, the driver has a bug.
CT
Almost everything we cover in this book works as well from an old-style, full-screen terminal as it does from an terminal window (like xterm) under the X Window System (Section 1.22). Actually, a lot of it works on an old printing teletype, too! In all of those cases, you're interacting with a Unix shell. This article covers things you should know about using a shell from an X window. We'll talk specifically about the X11R6 xterm client, but this generally applies to any window with a shell inside of it like GNOME terminal. This is a guided tour, so it helps to be at a workstation or other X display. If you can't take the tour, please scan through and look for the points I make along the way.
If you don't have an xterm window open, open one (by clicking on an icon, choosing a menu entry, or however you usually do it). We'll call this the "first window." Find its tty (Section 2.7). Next, in this first window, set an environment variable (Section 35.3) with a unique name and any value you want. You might call it FAVCOLOR and set the value to purple. Then, in that same window, type cd /tmp to change your current directory to /tmp. Finally, type xterm -rv -sb (with no & after its name); this should open a second xterm window. Here's what that first xterm should look like (we'll show C shell syntax here):
% tty /dev/pts/1 % setenv FAVCOLOR purple % cd /tmp % xterm -rv -sb (cursor sits here; there's no shell prompt)
When your new second xterm pops open, it should be in reverse video (swapped foreground/background colors, the -rv option) to make it easy to identify, with a scrollbar too. In it, type tty to get its tty number, which will be different from the previous xterm's. Run env or printenv (Section 35.3), and you should see the special environment variable (like FAVCOLOR) that you set. Type pwd; the current directory should be /tmp.[8]
If you've managed to follow this twisty series of steps, you've started a chain of processes (Section 24.3).
You can see that chain of processes by typing the command ps aux or ps -ef (Section 24.5). You should get lines something like these:
% tty /dev/pts/3 % ps -ef UID PID PPID C STIME TTY TIME CMD jpeek 675 1 0 May13 ? 00:00:14 xterm jpeek 681 675 0 May13 pts/1 00:00:00 zsh jpeek 14850 681 0 15:58 pts/1 00:00:00 xterm -rv -sb jpeek 14852 14850 0 15:58 pts/3 00:00:00 zsh jpeek 14992 14852 0 16:07 pts/3 00:00:00 ps -ef
This is the chain of processes that led to the second window. Let's start from the bottom and work up. From the ps -ef command,[9] you'll see that the ps command itself had PID (process ID) 14992; its parent's PID (PPID) was 14852. So the process that started the ps process is the shell running in that window: in my case, a Z shell, zsh, with PID 14852. Notice that both of these processes are running on the same tty (Section 2.7) named pts/3. That's a way to find all the processes in a particular window: check the tty name. This zsh is the shell running in this particular xterm. When you exit the shell (by typing CTRL-d or exit), the window will close too but don't try that yet! Instead, find the parent of the shell; it's the xterm process, which is running on are you surprised? another tty, pts/1. This makes sense, because you started xterm from another window, the first window. There's a shell running in the first window too; it's the zsh with PID 681. The parent of the first window's shell is, yes, another xterm, PID 675. And its parent has PID 1; this is init (Section 24.2), the "grandparent" of all processes on your system.
Your window system may not work quite this way. The parent of the top-level xterm might not be init. Also, an xterm could be owned by root instead of by you. Still, you should have a "chain" of processes, something like the one I described, on your system.
Why did we go through all this? One reason is so you'll know how to track the processes that lead to an xterm and to know what to look for if you have to kill (Section 24.12) a hung window or a process in a window. It's also to show that the environment from a parent window (here, the first window) the current directory, environment variables, and so on is passed to the child window (here, the second window). Finally, it's to show what happens when you close a window by exiting the shell: the shell terminates, so its parent xterm process terminates too.
So what happens to a shell running in a window if you close the window by clicking the "X" box on the window frame or by choosing the close or destroy commands in the window manager? The xterm gets a signal (Section 24.10), and the system hopes that it dies. But it may not die, and the process may stay around. Instead of trusting the window manager to kill a window and the processes in it, I tend to use ps so I know for sure that all the processes are gone. Knowing the stuff we've looked at here lets me identify a window and its processes.
But let's not kill things! Instead, in the second window, type exit at the prompt. The window should go away. And, in the first window, you should have a new prompt. (If you had started the second xterm in the background (Section 23.2), you could have kept working in the first window while the second window ran, too. But watch out for the zsh and ksh options named bg_nice and bgnice, respectively, which run background commands at lower priority. You probably don't want your new windows to run at low priority, so be sure that option isn't set.)
JP
xterm is an X client that runs a Unix process on a pty "inside" a window. By default, this process is a shell: an instance of the same shell you log into the system with. But it can be basically any Unix process. As you saw in Section 24.20, when the process exits, the xterm window closes because its child process has gone.
To override the default shell process in an xterm window, use the -e option (Section 5.22), followed by the command line to run the process. This must be the last thing on the xterm command line. If you want to open an xterm window with no scrollbar (the +sb option) and with the vi editor in it, to edit the log file named logfile, run the command below:
% xterm +sb -e vi logfile %
An xterm window should open with vi running inside it. If you don't know how to use vi, the best thing to do is to leave it alone until you've finished this example then press the ESC key, type :q, and press ENTER to exit vi. When vi exits, its window should close too, and you'll get another shell prompt.
I chose to have you run vi in a window because the vi process keeps running until you tell it to quit, and then the window closes. Other Unix processes that don't wait for a "quit" command will terminate as soon as they're done, and the window closes before you can see the process output. For example, let's say you want to display a file in an xterm window with a scrollbar. Start by choosing a file and using wc -l (Section 16.6) to count the number of lines. Then open an xterm and a scrollbar, with the scrolling buffer length set to just the right number of lines:
cat Section 12.2
% wc -l somefile 74 somefile % xterm -sl 74 -sb -e cat somefile %
What happened? Unless your window manager holds it there, the xterm window closes just after it opens. Why? Its child cat process exited, so the parent xterm did too. One easy answer is to use a shell that runs three commands. First is the command you want to run (here, cat). Next, echo a prompt. Finally, run the read command (Section 35.18) to pause until you give a dummy value just pressing ENTER will be enough to satisfy read, and then the shell will exit. Here's how:
% xterm -sl 76 -sb -e \ sh -c 'cat somefile; echo "Press RETURN to exit..."; read dummy'
(First, two notes. The backslash (\) isn't needed if you type the entire command on one line. And we've increased the scroll length to 76 because the echo and the newline after it add two lines of text.) Here, xterm starts a shell, but it's not the default shell (whatever that happens to be): it's the sh shell you specify after the xterm -e option. The sh option -c tells the Bourne shell to run the single command line from the following argument and then exit. The command line is in quotes to be sure the shell inside the xterm interprets it. The three commands are separated by semicolons (;) (Section 28.16). If your command line is really complicated, you might want to change the sh -c '...' to run a little shell script (Section 35.1) instead, like sh $HOME/lib/catter.
JP
In the X Window System, there's a process controlling every window. If the window (or its process) is frozen and you can't get rid of it, the easier way is usually to kill (Section 24.12) the process. As Section 24.20 explains, there may be a chain of processes running; the window could come from the parent process (as in the case of an xterm with a shell running inside of it) or it could be the child (such as when a shell script runs an X client like xmessage as in the nup script below). Your job is to use ps (Section 24.5) to track down the process(es) behind the window and kill the right one(s). We'll look at two different examples, then look at a shell script that opens a window and, later, closes the window by killing its process.
Let's say you're running vi in an xterm window, and the window seems to be frozen. Start with some detective work: open up another xterm window and run ps alwx or ps -ef. (If you're sure that all the processes in the window are owned by you and none were set user ID (Section 1.17) you can use run ps lwx, for example.) You want a listing that shows the chain of process IDs, parent-to-child, in that window. The tty (Section 2.7) of the shell inside the xterm will help you find the right one, if you know it. For example, I found vi 0568.sgm running on the tty pts/5, so the shell I want (the parent of vi) must also be on pts/5. From the shell's parent ID, I can find the PID of the xterm that started the shell. (I'll cut some of the columns in this listing to make it easier to read.)
% ps alwx UID PID PPID STAT TTY TIME COMMAND 1000 11287 1 S tty2 0:44 xterm -sb -sl 2000 ... 1000 11289 11287 S pts/5 0:04 bash2 ... 1000 2621 11289 S pts/5 0:00 vi 0568.sgm
|
Now you need to decide what process to kill. You could simply kill them all, assuming you own them (on some systems, the xterm process may be owned by root, so you can't kill it unless you can become superuser). But a little detective work can save trouble. For instance, see whether the xterm is still alive by trying to open its menus (Section 5.17). If a menu pops up, the problem is likely with the shell (here, bash2) or its child process (here, vi). Try killing the most junior process (here, vi) first:
-9 Section 23.3
% kill 2671 % ps 2671 PID TTY STAT TIME COMMAND 2671 pts/5 S 0:00 vi 0568.sgm % kill -9 2671 %
In this case, killing the process with a plain TERM signal didn't do the job; ps showed it was still running.  After this, if there's a shell prompt in the formerly frozen window, you're probably okay although you may need to reset the terminal modes if it's still acting weird. On the other hand, if the window is still frozen, kill the next-higher process here, bash2. Continue killing from the bottom up until the window is unfrozen or until the window closes.
The rule I gave in the previous section killing the lowest child process first is usually right for xterm windows, but not always right. For example, I'm using a development version of the Mozilla browser. It starts a series of child processes. But all the processes are designed to run as a unit, so killing the lowest child may just leave the browser in an unstable state. In cases like this, it's better to kill the top-level process (or one of the top, as I'll explain) and then check to be sure all the children have died.
Start with the long listing of processes. Find the parent and its children. Note that, depending on how they were started, they may not have a tty of their own in general, a window doesn't need a tty unless it's running a shell-oriented utility.
I started Mozilla from a menu on the window system. The window system was started from tty2 (by typing startx in the second virtual console (Section 23.12)). So the processes are "on" tty2, too. I happen to know that the ./psm processes are started by Mozilla. Although the parent psm is owned by the init (Section 24.2) process (PID 1), these were either disowned (Section 23.11) by Mozilla, or somehow the top-level psm process "lost" its parent. Finding this sort of disconnected process can be hard. One clue is that its PID is close to other Mozilla processes. Another clue may come when you use an output format like ps ux, which shows the starting time ("wall clock" time not the CPU TIME column above): you may see that the processes all started near the same time of day.
The first process in the list, the shell script (starting with sh), is what probably started the chain of processes running. Often, on Unix systems, a shell script sets the environment correctly, then starts another library program running. All the other processes here seem to have been started from the process with PID 9536, which has used 11 minutes 49 seconds of CPU time. Just to be safe, I'll kill both top processes at once:
% kill 9526 9536
The browser window closed, to I'm close to done. I also need to do another ps to be sure the other processes have vanished; note that they may need a few seconds to die gracefully on their own. Sometimes you'll get a zombie process (Section 24.19) that can't be killed, but it usually doesn't hurt anything unless your window's processes have been doing some hardware accesses and the zombie is tying up the hardware. Section 24.18 has some ways to clean up in that case.
A shell script that opens windows also may need a way to close them. The simplest way is by killing the window's process. You should be sure that whatever this process does, killing it won't cause it to leave old lock files and other "e-debris" around; it should exit cleanly when it gets a signal.
The xmessage client works well in a case like this. It opens a little window with a text message in it. If the user clicks a button in the window, xmessage terminates. But, in the example below, I want the shell script to close the window instead. Here's how it works:
Go to http://examples.oreilly.com/upt3 for more information on: nupndown
The shell script has two links (Section 10.4), or names: nup and ndown. I use them on my workstation, which no one else (usually) shares. When I run nup, the script brings the network up by dialing the modem and making a PPP connection.  When I'm done online, I run ndown. ndown disconnects the modem and closes the xmessage window by killing its process. Here's the basic script:
$! Section 27.17, '...' Section 28.14
#!/bin/sh pidfile=/tmp/.nup-pid case "$0" in *nup) xmessage -geometry 86x51+645+72 -fg white -bg red 'network up' & echo $! > $pidfile /sbin/ifup ppp0 ;; *ndown) pid=`cat $pidfile` case "`ps $pid`" in *xmessage*) kill $pid rm -f $pidfile ;; esac /sbin/ifdown ppp0 ;; esac
When the script is invoked as nup, it starts xmessage in the background (that is, disowned (Section 23.11)) and saves its PID in the temporary file. So xmessage will keep running after nup exits; its PID will be stored in the temporary file. Later, when the same script is invoked as ndown, it reads the temporary file to get the PID into a shell variable, runs ps to be sure that the process still exists and that its name still contains xmessage (in case another process has replaced xmessage in the meantime). If all's well, it kills that process to close the xmessage window, then removes the temporary file. Finally it shuts down the network.
The actual script (on the CD-ROM [see http://examples.oreilly.com/upt3]) does more error checking: verifying you're running the X window system before starting xmessage, ensuring the temporary file exists, and more. And, of course, this isn't foolproof by any means. For instance, if I click the "OK" button on the xmessage window, it will close while the modem is still on. But none of that is the point of this simple example script. It's to demonstrate how to close a window by killing its process. For instance, maybe your script opens an xclipboard window and wants to close it later if the user doesn't do so first.
JP
[1] This isn't true when the subprocess is execd from the parent process without a fork first. Section 24.2 explains.
[2] When you use the shell's exec (Section 35.5) command, it does not start a subprocess.
[3] Some vendors add other fields, such as the processor number for multiprocessors and additional or different process states (as in the AIX K field). These codes may differ from vendor to vendor: for example, the 0 code under Stardent Unix means a process that is actually running (and R means runnable), while 0 under AIX means a nonexistent process.
[4] It's usually also a good idea to be sure that the input and outputs are redirected (Section 43.1, Section 36.16) away from the terminal, maybe to the system console instead. Signal 15 is SIGTERM, which is the signal kill sends by default. In this command, you need to specify it explicitly, for obvious syntactic reasons.
[6] The MH email system also has a command named pick. If you use MH, or frontends like exmh or mh-e, you could rename this script to something like choose.
[7] This trick uses the shell's built-in wildcard matching (Section 1.13) to show you the shell's name we hope. If you get an answer like /bin/bas?, or multiple answers that don't include /bin/bash, try another shell name. (Maybe your bash is in /usr/local/bin, for instance.) If you get an answer like No more processes, though, your echo command probably isn't built in.
[8] If your setup files assume you're in your home directory (Section 3.7), you may have some problems.
[9] Note that, if your system's process ID numbers have "recycled" and started over from 1, the ps command may not have the highest number.
| CONTENTS |


Service
Bindings
Bind an App
Bind
Plan
Streaming Application Logs
Credentials
Modify
RENAME
CANCEL
Delete Service
This service will be delete.
DELETE SERVICE


Hi! I'm Shubhani
I have keen interest in Full Stack Development and Data Science
I am very curious to learn and explore a new jounery in coding!
I have knowledge of
Python
HTML5
CSS3
JavaScript
C Programming
SQL


1st and Pine
Our flagship location. When Pat’s grandmother Jenny (second from left) came up with the idea for salmon cookies, Pat recognized the brilliance and went all in. Together, they revolutionized the concept of savory desserts. Today the whole family works here, even the kids Norma and Liam!
- Visit us:
- 314 Pine Ave E, Seattle 98134
- Be sure to come between the hours of:
- 6AM and 8PM
- Give us a call:
- (360) 314-FISH (3474)
- Shoot us an email:
- pine@salmoncookies.com


Reset
Raise temperature
Lower temperature
Power Save Mode on
Power Save Mode off
Power saving mode is
on


'Bringing Out the Dead' (1999)
A movie review by Walter Frith
<EMAIL_ADDRESS>Member of the 'Online Film Critics Society' http://www.ofcs.org
Robert Richardson's familiar light filled cinematography showers scenes of close up intimacy the way they have in many other films but it is particularly startling in the case of 'Bringing Out the Dead'. Set in the early 90's in New York City, Nicolas Cage stars as a paramedic named Frank Pierce, a man haunted by the people he couldn't save and has a re-occurring vision of one particular young woman whom he sees while driving in his ambulance every time he looks at some of the city's derelicts. Richardson's photography echoes the notion of spirituality as those who believe in the spiritual nature of mankind will connect with the striking camera effects that give way to believing the soul leaves the body at the moment of death.
Cage's performance as the paramedic is brilliant. Sort of an up tempo variation on his performance in 'Leaving Las Vegas'. In that film from 1995 for which Cage won the Best Actor Oscar, he played an alcoholic L.A. writer who was determined to move to Las Vegas and drink himself to death within 30 days. In 'Bringing Out the Dead', Cage looks like he did in the above mentioned film. Pale, stressed out with bad hair, bags under his eyes and an overall structure of a man not in good physical health. Only this time the characterization that Cage has brought to the screen is frenzied rather than sedated. His colleagues in the paramedic business who travel with him from time to time are Larry (John Goodman), Marcus (Ving Rhames) and Tom (Tom Sizemore). All are men of different personalities.
Director Martin Scorsese has made a relentless and lacerating film and this film is vintage Scorsese. It reaps with scenes of hollow urban destitution like 'Mean Streets', and 'Taxi Driver'. When Scorsese is on target with his visuals, he photographs and cuts his films with mesmerizing accuracy. Scorsese keeps 'Bringing Out the Dead' from being just another NYC story of grit and keeps a re-occurring theme elevated for the film's entire running time. Frank Pierce (Cage) is seen at the beginning of the film responding to a call where an elderly man has had a heart attack. Frank befriends his daughter (Patricia Arquette) and keeps checking on her father's progress throughout the course of the film.
The film is also like a big screen version of television's 'ER'. The emergency room at the hospital has all the characters you would expect to find in a big city hospital. There is the stern security guard wearing sunglasses who is determined to keep order, the head nurse who questions people as to why the hospital should help people like drug addicts when they brought these problems on themselves, the head physician who complains that there is a constant need for space and the repeat patient who is strapped to a table on wheels in the hallway, going out of his mind because he can't get his drug fix.
'Bringing Out the Dead' is anything but conventional film making. Believe it or not, from all of the problems its characters face as true examples of human beings, the film has a surprising sense of humour. Writer Paul Schrader, whom I have always disliked in most cases and who made the most depressing film I've ever seen as both writer and director of 1998's 'Affliction', does an excellent job as author of the 'Bringing Out the Dead' screenplay. He constructs the film in a manner that grabs your attention right away from the opening scene and never lets up. However, a lot of the credit for this belongs to Joe Connelly, who wrote the novel on which this film is based. The only thing that prevents this movie from being a five star accomplishment is that it is not an entirely new version of events from either Scorsese, Cage of Schrader. As good as the film is, it is the definition of re-invention. You can see that all involved are doing a variation on past work and consequently, it just misses being a great film but is excellent film making but won't bring Scorsese the long awaited Oscar he deserves and may some day win.
OUT OF 5 > * * * *
Visit FILM FOLLOW-UP by Walter Frith http://www.cgocable.net/~wfrith/movies.htm
* * * * * - a must see * * * * 1/2 - don't miss it * * * * - an excellent film * * * 1/2 - a marginal recommendation * * * - can't quite recommend it * * 1/2 - don't recommend it * * - avoid it * 1/2 - avoid it seriously * - avoid it AT ALL COSTS 1/2 - see it at your own risk zero - may be hazardous to your health
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


{% extends "base.html" %} {% block content %}
W-what made you think I would have such a page, anyway? Kimochi warui...


2017-11-01
last modified: 2022-12-16
== !
At the most basic level, anything could count as "data" with possibly a personal character to it, including comments written about somebody in a personal notebook.
In practice, "data" starts to to be considered as such when it can be processed automatically or when it consists in structured records that can be used to facilitate the retrieval of specific information on specific individuals.
→ Hint: paper records, filing systems, databases.
Personal data are any anonymous data that can be double checked to identify a specific individual (e.g. fingerprints, DNA, or information such as “the son of the doctor living at 11 Belleville St. in Montpellier does not perform well at school”).
Personal data is data that an individual has the right to keep private. How and why is privacy an issue?
Privacy is mentioned in the Article 12 of the 1948 Universal Declaration of Human Rights:
No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honor and reputation. Everyone has the right to the protection of the law against such interference or attacks.
This article from the Declaration is found in similar forms in most of the conventions on human rights in the world.
This right to privacy enables individuals to define their identity in relation to the world, by giving each individual the power to control what to keep for themselves, and what to reveal / share with the world.
In 2005, a report on Privacy in the Digital Environment by the Haifa Center of Law & Technology develops:
The right to privacy is our right to keep a domain around us, which includes all those things that are part of us, such as our body, home, property, thoughts, feelings, secrets and identity.
The right to privacy gives us the ability to choose which parts in this domain can be accessed by others, and to control the extent, manner and timing of the use of those parts we choose to disclose.
In addition to shaping an individual’s own personal sphere and identity, privacy also underpins the development of a relation between the individual and the society she is part of:
→ when an individual’s privacy is secured, they don’t have to fear that their personal opinions and activities (as simple as reading a newspaper) will endanger them as citizens.
→ this gives liberty to individuals to develop political expressions which do not necessarily conform with the power structure in place. This would be much harder if everyone’s political opinions could not be kept private.
Privacy is a social norm which transforms as societies evolve. Since the 2000s, a couple of tendencies can be identified:
increasing tracking of the digital traces left by individuals by companies which use these traces for ad targeting and data reselling.
increasing state surveillance through digital means, against security threats and unspecified goals.
broader public acceptance of new forms of violations to privacy.
For example, TV shows where participants are filmed 24/24 and where they reveal their (real or supposed) intimacy, dates back only from the late 1990s.
Thanks to whistleblowers like Edward Snowden, a former contractor for the National Security Agency - NSA, the extent of privacy breaches by governmental agencies is now better known.
This trailer for "CitizenFour" gives a sense of the dangers whistleblowers face when revealing how governmental agencies spy on their citizens:
Journalists, academics, activists and NGOs such as the Electronic Frontier Foundation make the case that:
consumers are insufficiently aware and sensitive of how much information is captured in the normal conduct of their lives, just by using mobile phones and apps, web browsing, and increasingly in public places.
citizens are insufficiently aware and sensitive of the breach of their privacy by security agencies of their own country of residence, and by other countries.
Many citizens consider that if they don’t break the law, then they have "nothing to hide".
Similarly, consumers might find that bargaining their private data against a free service and some targeted ads, is a good deal.
Sociologist of technology Zeynep Tufekci goes further:
Her argument is that besides "surveillance" and "lack of privacy", companies like Google and Facebook developing a business model based on ad targeting by analytics on personal data, design a persuasion architecture which can be used / highjacked for political purposes.
Tufekci does not argue that Google, Facebook or the likes inherently have anti-democratic purposes, but that:
they develop of an information architecture which has the potential to shape opinions of crowds,
they do so without transparency
some past experiments on voting in the US, and current developments on electronic surveillance in China, show that the power of these technologies has already consequences in the real world:
The collection and treatment of personal data by businesses has far reaching implication, and should not be considered merely from a legal standpoint by firms.
The topic engages the Corporate social responsibility of the firm.
The nature of the business model itself - profiling consumers in the most specific way - has profound consequences on the design of the environment surrounding individuals.
What are the next steps? Several trends can be identified:
Some voices question the business model: are personalized ads based on personal data as effective as the market valuation of Facebook suggests? How much is just scam? Some voices warn against the extent of the fraud in digital ads, as the video below shows:
Legislation by political authorities to protect the public interest, especially via an obligation for transparency, in the face of more personal data being collected, for a larger variety of purposes.
A deepening of the current model with more personal data being collected, in private spaces (homes) and behavior in public places (crowd management in streets, stadiums, etc.):
Echo Alexa is a home assistant with a conversational interface, providing services personalized with the data provided by the user.
Find references for this lesson, and other lessons, here.
This course is made by Clement Levallois.
Discover my other courses in data / tech for business: https://www.clementlevallois.net


Where to find those pesky kids playing hide and seek in Shenmue 3
by Elizabeth HengesWhere are the hide and seek locations in Shenmue 3? When you first visit the Sunflower Field in Yu Suzuki's third Shenmue outing, you’ll run into a group of kids. They’re willing to help you with your investigation into the whereabouts of the thugs in Bailu Village, on one condition.
Before they're ready to assist you, you need to play a game of hide and seek with them. You have limited time with which to complete the game, and it’s required to move the central plot forward. So, naturally, I'm going to help you find each one of them with this Shenmue 3 hide and seek guide.
Shenmue 3 hide and seek locations
This minigame begins automatically when you first enter Sunflower Fields, and from there, you have about three in-game hours to find all four children. They’re all still within the area, but it can be difficult to find them if you don't know where to look. You need to wait until tomorrow if you fail, so I'm here to ensure that doesn't happen.
First head into the field of sunflowers. The child hiding amid the flora will take the longest to find, so don't worry if you find yourself taking a wrong turn. At the very least, you'll have the chance to pick up some nice herbs along the way. The tough-to-find child is near the end of the field, hiding in the tall grass behind some sunflowers. A cutscene will trigger when you’re close, so you'll know when you're in roughly the right spot.
Now, exit the maze of sunflowers via the closet exit: the next child is very close by. He’s hiding behind the carts you see up ahead.
To down, two to go. Head behind the row of houses, and you’ll see some pens with cows in them. If you look at the houses, you’ll see one with a ladder: the child is sitting on the roof, so approach the ladder in order to trigger the next cutscene.
Image 1 of 4
Image 2 of 4
Image 3 of 4
Image 4 of 4
While the previous three children can be found in any order, this child can only be found last, as finding him progresses the plot. Where he’s hidden is also kind of cheating: rather than outside, he’s hiding inside someone’s house. From where you found the kid on the ladder, you can see the roof of another house.
Approach the door to find the last child; you’ll be able to move forward the plot by investigating Xu’s house. Now you're all done. Make sure to pick up the forklift toy and give it back to the kid later.


{% extends "base.html" %} {% block content %} Thank you. You will receive an activation email shortly, please click on the link to verify your email address. {% endblock %}


$20 for a Growler + Fill
Delivery is Free!!
We have 12 Tapps Now!
Rudys Red Amber
Rudys IPA
Rudys Blonde
Rippin Pale Ale - Sunriver Brew
Viscious Mosquito IPA - Sunriver Brew
Fuzzytale Hefe - Sunriver Brew
Pinapple Express Cider - Jester & Judge
Blackberry Cider - Atlas Cider
Rotating Cider - Ask your Host
Rotating Nitro - Ask your Host
Blue Moon
Coorslight
Washington Meets Oregon
Pineapple Express Cider Mixed with Blackberry Cider!!
Up to 2 Growlers per delivery!!!!


public class CommonAural
extends java.lang.Object
| Modifier and Type | Field and Description |
|---|---|
int |
azimuth
The "azimuth" property.
|
java.lang.String |
cueAfter
The "cueAfter" property.
|
java.lang.String |
cueBefore
The "cueBefore" property.
|
int |
elevation
The "elevation" property.
|
int |
pauseAfter
The "pauseAfter" property.
|
int |
pauseBefore
The "pauseBefore" property.
|
int |
pitch
The "pitch" property.
|
int |
pitchRange
The "pitch-range" property.
|
int |
playDuring
The "playDuring" property.
|
int |
richness
The "richness" property.
|
int |
speak
The "speak" property.
|
int |
speakHeader
The "speak-header" property.
|
int |
speakNumeral
The "speak-numeral" property.
|
int |
speakPunctuation
The "speak-punctuation" property.
|
int |
speechRate
The "speech-rate" property.
|
int |
stress
The "stress" property.
|
int |
voiceFamily
The "voice-family" property.
|
int |
volume
The "volume" property.
|
| Constructor and Description |
|---|
CommonAural(PropertyList pList)
Create a CommonAbsolutePosition object.
|
public int azimuth
public java.lang.String cueAfter
public java.lang.String cueBefore
public int elevation
public int pauseAfter
public int pauseBefore
public int pitch
public int pitchRange
public int playDuring
public int richness
public int speak
public int speakHeader
public int speakNumeral
public int speakPunctuation
public int speechRate
public int stress
public int voiceFamily
public int volume
public CommonAural(PropertyList pList)
pList
- The PropertyList with propery values.Copyright 1999-2020 The Apache Software Foundation. All Rights Reserved.


| PostgreSQL 9.5.19 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 46. Logical Decoding | Next |
Logical decoding is the process of extracting all persistent changes to a database's tables into a coherent, easy to understand format which can be interpreted without detailed knowledge of the database's internal state.
In PostgreSQL, logical decoding is implemented by decoding the contents of the write-ahead log, which describe changes on a storage level, into an application-specific form such as a stream of tuples or SQL statements.
In the context of logical replication, a slot represents a stream of changes that can be replayed to a client in the order they were made on the origin server. Each slot streams a sequence of changes from a single database, sending each change exactly once (except when peeking forward in the stream).
Note: PostgreSQL also has streaming replication slots (see Section 25.2.5), but they are used somewhat differently there.
A replication slot has an identifier that is unique across all databases in a PostgreSQL cluster. Slots persist independently of the connection using them and are crash-safe.
Multiple independent slots may exist for a single database. Each slot has its own state, allowing different consumers to receive changes from different points in the database change stream. For most applications, a separate slot will be required for each consumer.
A logical replication slot knows nothing about the state of the receiver(s). It's even possible to have multiple different receivers using the same slot at different times; they'll just get the changes following on from when the last receiver stopped consuming them. Only one receiver may consume changes from a slot at any given time.
Note: Replication slots persist across crashes and know nothing about the state of their consumer(s). They will prevent removal of required resources even when there is no connection using them. This consumes storage because neither required WAL nor required rows from the system catalogs can be removed by VACUUM as long as they are required by a replication slot. So if a slot is no longer required it should be dropped.
Output plugins transform the data from the write-ahead log's internal representation into the format the consumer of a replication slot desires.
When a new replication slot is created using the streaming replication interface, a snapshot is exported (see Section 9.26.5), which will show exactly the state of the database after which all changes will be included in the change stream. This can be used to create a new replica by using SET TRANSACTION SNAPSHOT to read the state of the database at the moment the slot was created. This transaction can then be used to dump the database's state at that point in time, which afterwards can be updated using the slot's contents without losing any changes.


Facebook Story Search
{{requestCount}} feeds
{{requestButton}}
Facebook Story Search
Search all the posts on your Facebook
The application supports English and Thai languages only,
the messages of other languages may not be searchable.
Privacy Policy
Search
Full-Text Search
Relevant (Experiment)
Search: {{searchResult.keyword}} ({{searchResult.number}} results)
{{feed.from.name}}
{{feed.updated_time}}
{{feed.message}}
{{feed.caption}}
{{feed.description}}
Score: {{feed.score.toFixed(4)}}
Show More


Data Access (bpy.data)¶
This module is used for all Blender/Python access.
-
bpy.
data
¶ Access to Blender’s internal data
Type: bpy.types.BlendData
import bpy
# print all objects
for obj in bpy.data.objects:
print(obj.name)
# print all scene names in a list
print(bpy.data.scenes.keys())
# remove mesh Cube
if "Cube" in bpy.data.meshes:
mesh = bpy.data.meshes["Cube"]
print("removing mesh", mesh)
bpy.data.meshes.remove(mesh)
# write images into a file next to the blend
import os
with open(os.path.splitext(bpy.data.filepath)[0] + ".txt", 'w') as fs:
for image in bpy.data.images:
fs.write("%s %d x %d\n" % (image.filepath, image.size[0], image.size[1]))


Version 0.7.4
yarn setup:project
to install dependencies, build project and start serve.yarn serve
to build the project for development and serve.yarn build:prod
to build the project for production.yarn build:ssr
to build the project for production with server side rendering.yarn start
for start server with server side.yarn conventional-changelog
.yarn compodoc
or yarn compodoc:serve
for serve in browser.yarn analyzer
.ng generate component component-name
to generate a new component. You can also use ng generate directive/pipe/service/class/module
.ng test
to execute the unit tests via Karma.ng e2e
to execute the end-to-end tests via Protractor.yarn build:dev
.yarn lint
..ci
folder are two prepared files for Heroku and AWS deploy. You can choose one of these.