Suspending processes

Roy Smith roy at phri.UUCP
Tue Jan 13 14:39:33 AEST 1987


In article <836 at A60.UUCP> lee at 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 at 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 at 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!"



More information about the Comp.unix.questions mailing list