Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!cmcl2!phri!roy From: roy@phri.UUCP (Roy Smith) Newsgroups: comp.unix.questions Subject: Re: Suspending processes Message-ID: <2557@phri.UUCP> Date: Mon, 12-Jan-87 23:39:33 EST Article-I.D.: phri.2557 Posted: Mon Jan 12 23:39:33 1987 Date-Received: Tue, 13-Jan-87 19:22:18 EST References: <836@A60.UUCP> Reply-To: roy@phri.UUCP (Roy Smith) Organization: Public Health Research Inst. (NY, NY) Lines: 121 In article <836@A60.UUCP> lee@A60.UUCP (G. Lee) writes: > Does UNIX provide a standard way to suspend a processes ( stop it > from getting CPU time )? First, the simple answer. If you are on one of the common versions of Berkeley Unix (4.3 or 4.2, and I think, 4.1 BSD), you can just type a control-Z to suspend your job if it's currently running. If you already have the job in the background (because you started it with a "&" after the command), you have to say "stop %N", where "N" is the job number shown in [brackets] when you run the "jobs" command. Often, there will only be one job, and thus "N" will be "1". The question, as phrased, is a bit ambiguous, but I think this is what lee was after. The job (more or less, but not quite, the same as a process) doesn't eat up any more CPU time, and can either be killed or restarted at a later time. See "An introduction to the C shell" for more details, especially section 2.6, "Jobs: Background, Foreground, or Suspended". As Doug Gwyn pointed out, control-Z may also work on some versions of System-5 UNIX, but I have no experience with that. Now some (hopefully useful) comments, aimed both at people asking questions and those answering them. When asking a question, it is important to mention what type of system you are working with. There are dozens (hundreds?) of versions of Unix systems out there, but most of the modern ones can be classified into one of two broad classes -- Berkeley or AT&T Unix. The former is identified by having some variation of 4.N in its name, where N is likely to be 1, 2, or 3. The latter will probably have a version number along the lines of "System 5" or "System V", possibly followed by "version X" and/or "release Y". Sometimes you'll see this shortened to "Sys5", SysV", or even "S5" or "SV". If your system has been packaged by somebody other than Berkeley or AT&T, it may very well have random extra bits of version number in it. Usually, when you log in, one of the first things the system will type at you is the version number. For example, when I log in on my Sun workstation, I get: Sun UNIX 4.2 Release 3.1FCS (GENERIC) #3: Fri Nov 21 12:22:43 PST 1986 It just so happens that the information contained in that line is in decreasing order of importance as you read from left to right; this will often be the case. If I were to tell somebody what kind of system I was using, I would say "4.2 Berkeley Unix, Sun version 3.1FCS". When in doubt, it's generally better to give more information rather than less. Now, for people answering questions, please keep in mind that this is unix-questions, not unix-wizards. Not to pick on anybody in particular, but let me tear apart two answers to the above question. I'll leave the names off because they really aren't important. --> Message-ID: <8299@topaz.RUTGERS.EDU> --> In BSD you could send a process a SIGSTOP (kill -STOP) and stop the --> process that way. Maybe I'm over-reacting, but this strikes me as a useless answer. Why? Lot's of reasons. Starting at the beginning, what's "BSD" mean? *I* know what it means, and *you* know what it means, but to a typical neophyte, it's just a confusing acronym. Second, how does one go about sending a process a SIGSTOP signal? Just typing "kill -STOP" when you get a "% " doesn't do anything (much to my surprise, it doesn't generate an error message, on either my 4.2 Vax or my 4.2/3.1 Sun; note the lapse into jargon). You have to first hunt up the process id (or job number) and know what to do with it. Besides, for the usual case where the shell you are talking to is the shell that spawned the process/job in question, doing "stop" is more straight-forward than doing "kill -SIGSTOP". --> Message-ID: <5507@brl-smoke.ARPA> --> There isn't any universal way of doing this, and on some UNIXes --> there is no way at all. Around SVR2.1 or so, a "switch" character --> was added for terminals, usually set to ^Z or ^Y, that operates in --> conjunctions with the "shl" poor-man's process manager to control --> processes more or less as you seem to wish. 4.1BSD and later include --> a fancier "job control" mechanism that does similar things in --> conjunction with a shell that understands this environment (C-shell, --> BRL Bourne shell, or Korn shell). The System V scheme is cleaner but --> doesn't provide any way for a process to notice that the terminal --> display has been asynchronously messed-up by the "shl" operations, --> which is sometimes quite a nuisance when your resumed screen-oriented --> software doesn't have any way to request a screen repaint. --> --> The best facility I've seen for this is the /proc mechanism of 8th --> Edition UNIX. Unfortunately I haven't seen this adopted in any --> generally-available version of UNX. Starts well; points out that there is more to the question than meets the eye, and warns the reader that this answer may or may not pertain to the particular system he is using. Unfortunately, we then see a quick lapse into jargon. If "SVR2.1" isn't a meaningless string of jibberish to the uninitiated, I don't know what is. The next couple of lines skirt around part of the answer, but never quite come out and say "type either a control-Z or a control-Y, depending on how your particular system is set up". The comparison of the Sys5 and BSD flavors of job control is just extra verbiage to wade through for the novice who simply wants to know how to get his job stopped. The bit about v8 /proc stuff is also extraneous and confusing to the novice. Either explain what /proc is all about, at a level a non-computer type can understand, or leave it out entirely. Given that most people aren't likely to see it at all, I would opt for the latter. Well, I've ranted long enough. I hope I've done some good, and I hope that the people I picked on to use as examples aren't too offended by my editorializing. In the environment where I work (largely non-computer types, including many who have never seen a computer before they came to work here), I've grown to be very sensitive to the problems of the novice. If you don't want to lose your audience, you have to quickly figure out what level of answer they can handle, and adjust your explanation accordingly, without talking down to them. On a forum like usenet, where you can't see the person you are talking to, this is twice as hard as it is person-to-person. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"