I'm helping someone to improve a CMS-type of web system. This web
system sometimes needs to run some background processes --- such as send
a batch of e-mail or other process that takes a while to finish.
I see the challenge here as just writing something that will look like a
very basic UNIX shell --- so I'll call it ``web-api-shell'' from now on. >(``Web'' because it will be used by a web system through some API.)
This thing must run really well. It has to be flawless. I'm looking
for design principles and advice.
(*) Where will it run
It will run on GNU systems running the Linux kernel.
(*) My own thoughts
The interface to shell will be through HTTP requests, so this shell will >likely be a web server of some sort. But before I get involved in the
web at all, I need the shell working flawlessly.
So I need a laboratory first. I could write a program that reads some
named pipe on disk to get commands such as ``run this or that'' while I
work. (Later I can write a web server replacing this named-pipe
interface.)
Just like a UNIX shell, this web-api-shell must know all every process
it runs. I suppose the work is essentially fork(), execve() followed by >waitpid().
One concern I have is the following. Is it possible for a process to
simply ``get out of'' the shell? What do I mean by that? A process
that does fork() and puts itself into background would leave the >web-api-shell's control, wouldn't it?
Meredith Montgomery <mmontgomery@levado.to> writes:
I'm helping someone to improve a CMS-type of web system. This web
system sometimes needs to run some background processes --- such as send
a batch of e-mail or other process that takes a while to finish.
I see the challenge here as just writing something that will look like a >>very basic UNIX shell --- so I'll call it ``web-api-shell'' from now on. >>(``Web'' because it will be used by a web system through some API.)
This thing must run really well. It has to be flawless. I'm looking
for design principles and advice.
(*) Where will it run
It will run on GNU systems running the Linux kernel.
(*) My own thoughts
The interface to shell will be through HTTP requests, so this shell will >>likely be a web server of some sort. But before I get involved in the
web at all, I need the shell working flawlessly.
So I need a laboratory first. I could write a program that reads some >>named pipe on disk to get commands such as ``run this or that'' while I >>work. (Later I can write a web server replacing this named-pipe >>interface.)
Just like a UNIX shell, this web-api-shell must know all every process
it runs. I suppose the work is essentially fork(), execve() followed by >>waitpid().
One concern I have is the following. Is it possible for a process to >>simply ``get out of'' the shell? What do I mean by that? A process
that does fork() and puts itself into background would leave the >>web-api-shell's control, wouldn't it?
Define 'get out of' in this context.
Any process forked by a shell is by definition a child of the shell;
the only way it can become a child of some other process (pid=1
(init)) is for the shell to "orphan" the child by exiting before the
child exits.
The shell itself is known as a 'session leader'. A session consists
of one or more 'process groups' (a concept developed originally in BSD4). Each process group contains one or more processes. One, and only
one, of the process groups within a session is considered the foreground process group and is allowed access to the "controlling" terminal of the session. Background process groups run in the background until they need
to access the terminal, in which case a signal is thrown (e.g. SIGTTIN) and the process will be suspended until the shell makes the process group the foreground process group.
You'll find a great deal of useful information, if you can find a
copy, in:
Session Management in System V Release 4
Usenix Conference Proceedings Winter 1989 pp. 365-375.
Tim Williams (Tim was an engineer at AT&T/USL).
See setsid(2), getsid(2), setpgid(2), setpgrp(2), tcgetsid(3)
and other man pages for more information.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/setsid.html# https://pubs.opengroup.org/onlinepubs/9699919799/functions/setpgid.html#
Note that the full source is available on-line for a dozen
or more open source shells (Korn shell, Bourne Again Shell, Bourne Shell,
C Shell, and many others); useful to see how they handle
sessions.
scott@slp53.sl.home (Scott Lurndal) writes:
One concern I have is the following. Is it possible for a process to >>>simply ``get out of'' the shell? What do I mean by that? A process
that does fork() and puts itself into background would leave the >>>web-api-shell's control, wouldn't it?
Define 'get out of' in this context.
Say the shell runs a process P and suppose P forks() --- creating Q ---
then P exits, leaving Q orphaned. I believe Q's parent is now process
1. I wonder if this creates difficulties to my objectives.
I'm helping someone to improve a CMS-type of web system. This web...
system sometimes needs to run some background processes --- such as send
a batch of e-mail or other process that takes a while to finish.
I see the challenge here as just writing something that will look like a
very basic UNIX shell --- so I'll call it ``web-api-shell'' from now on. (``Web'' because it will be used by a web system through some API.)
This thing must run really well. It has to be flawless. I'm looking
for design principles and advice.
(*) Where will it run
It will run on GNU systems running the Linux kernel.
(*) My own thoughts
The interface to shell will be through HTTP requests, so this shell will likely be a web server of some sort. But before I get involved in the
web at all, I need the shell working flawlessly.
I'm helping someone to improve a CMS-type of web system. This web
system sometimes needs to run some background processes --- such as send
a batch of e-mail or other process that takes a while to finish.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 85:59:58 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,099 |
Messages: | 5,277,030 |