Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #13667

Re: a kind of a web-shell-api for managing long running processes

Show all headers | View raw

scott@slp53.sl.home (Scott Lurndal) writes:

> 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.

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.  It's not
clear to me.  (Perhaps this project should use a PID namespace provided
by the Linux kernel, say.  Perhaps I'm worried about irrelevant things.
Maybe I should just run every process under a certain uid and search the
process table by that uid and these are the processes I should manage:
on the web, I will list out all current background processes and let the
sysadmin send signals to them --- kill them, for example.  I can't let
the sysadmin send signals to other [unrelated] processes and I should
always display every process that directly or indirectly was born by way
of this background-process-manager, so I must book-keep every process
spawned.)

> 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.

Written down.  Thanks.

> 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.

Thank you so much for info.  Very appreciated.

Back to comp.unix.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

a kind of a web-shell-api for managing long running processes Meredith Montgomery <mmontgomery@levado.to> - 2021-12-30 17:16 -0300
  Re: a kind of a web-shell-api for managing long running processes scott@slp53.sl.home (Scott Lurndal) - 2021-12-30 21:55 +0000
    Re: a kind of a web-shell-api for managing long running processes Meredith Montgomery <mmontgomery@levado.to> - 2021-12-31 08:06 -0300
      Re: a kind of a web-shell-api for managing long running processes scott@slp53.sl.home (Scott Lurndal) - 2021-12-31 15:28 +0000
  Re: a kind of a web-shell-api for managing long running processes Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-01-01 00:46 +0000
  Re: a kind of a web-shell-api for managing long running processes Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-01-01 01:03 +0000

csiph-web