I'd like to start a web server (cl-http) process from a remote client
so that it keeps running after the client connection is closed.
Would using cron to start the lisp process be a viable way of doing
this? Right now I don't see a way of anticipating and handling all the
possible errors...
Ben
On 6 Jan 2005 21:26:10 -0800, <·········@hotmail.com> wrote:
> I'd like to start a web server (cl-http) process from a remote client
> so that it keeps running after the client connection is closed.
>
> Would using cron to start the lisp process be a viable way of doing
> this? Right now I don't see a way of anticipating and handling all the
> possible errors...
detachtty
seems to be the standard answer to that question
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Rob Warnock
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <7q6dndzOgeKf1UPcRVn-sg@speakeasy.net>
GP lisper <········@clouddancer.com> wrote:
+---------------
| <·········@hotmail.com> wrote:
| > I'd like to start a web server (cl-http) process from a remote client
| > so that it keeps running after the client connection is closed.
|
| detachtty
| seems to be the standard answer to that question
+---------------
I second that! "Detachtty" is great! Unlike "screen"[1], it does not
require a real TTY at startup, thus can readily be run by system
init files at bootup time. See <http://www.cliki.net/detachtty>
for more info.
-Rob
[1] Though newer versions of "screen" might have fixed that. (?)
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <······················@speakeasy.net>, Rob Warnock wrote:
> GP lisper <········@clouddancer.com> wrote:
> +---------------
> | <·········@hotmail.com> wrote:
> | > I'd like to start a web server (cl-http) process from a remote
> | > client so that it keeps running after the client connection is
> | > closed.
> |
> | detachtty seems to be the standard answer to that question
> +---------------
>
> I second that! "Detachtty" is great! Unlike "screen"[1], it does not
> require a real TTY at startup, thus can readily be run by system
> init files at bootup time. See <http://www.cliki.net/detachtty> for
> more info.
"screen -d -m -S <name>" to start a detached session has worked since
at least v3.7.1 in 1995[1]; patchlevel.h implies that it might have
worked as far back as 1992. When did you start using it?
-- Larry
[1] At least, 3.7.1 compiled on my machine this morning will do it.
From: Rob Warnock
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <TJudnQxIisfCeHzcRVn-gw@speakeasy.net>
Larry Clapp <·····@theclapp.org> wrote:
+---------------
| Rob Warnock wrote:
| > I second that! "Detachtty" is great! Unlike "screen"[1], it does not
| > require a real TTY at startup, thus can readily be run by system
| > init files at bootup time. See <http://www.cliki.net/detachtty> for
| > more info.
|
| "screen -d -m -S <name>" to start a detached session has worked since
| at least v3.7.1 in 1995[1]; patchlevel.h implies that it might have
| worked as far back as 1992. When did you start using it?
+---------------
Uh... Circa 1985, on a DEC VT320 [IIRC]!! ;-} ;-}
Granted, that was probably one of Oliver Laumann's earliest
versions, but I used it off & on until 1989 when I went to
SGI and started using bit-mapped displays with multiple windows
[though still used it some when dialing in from home]. Then
X Windows came along, and I admit I haven't used it much lately,
but had assumed the "needs real TTY (or PTY) as parent" limitation
still existed from various comments in the "detachtty" documentation.
My apologies for any mistaken aspersions cast upon "screen".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
GP lisper wrote:
> On 6 Jan 2005 21:26:10 -0800, <·········@hotmail.com> wrote:
> > I'd like to start a web server (cl-http) process from a remote
client
> > so that it keeps running after the client connection is closed.
> >
> > Would using cron to start the lisp process be a viable way of doing
> > this? Right now I don't see a way of anticipating and handling all
the
> > possible errors...
>
> detachtty
>
> seems to be the standard answer to that question
I had some problems with compiling detachtty on solaris 8, so I pkg-got
screen instead. Terminal multiplexing was the answer and gnu screen
does this in exactly the way needed for this problem. It also has some
assorted features that make remote server management much easier. I'd
looked at this earlier and for some reason I didn't follow through with
it. A solaris8-ready version of detachtty would also be good if anyone
knows of one...
This was great - thanks for all the helpful ideas!
Ben
> --
> Everyman has three hearts;
> one to show the world, one to show friends, and one only he knows.
From: ·········@cern.ch
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <yzovfa961sz.fsf@cern.ch>
Ben> I'd like to start a web server (cl-http) process from a remote client
Ben> so that it keeps running after the client connection is closed.
You might want to use detachtty for this. For added fun, you can start
swank then connect to the process with emacs/slime at your leisure:
$CMUCL/bin/detachtty --dribble-file $TMP/xtst.dribble \
--log-file $TMP/xtst.log \
$TMP/xtst.socket \
$CMUCL/bin/lisp \
-noinit \
-load /whatever/starts/your/server.lisp \
-load $SLIME/swank-loader.lisp \
-eval '(swank:create-server :dont-close t)'
Ole
From: Espen Vestre
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <kwzmzlv8ze.fsf@merced.netfonds.no>
·········@hotmail.com writes:
> I'd like to start a web server (cl-http) process from a remote client
> so that it keeps running after the client connection is closed.
YMMV, in addition to using screen etc. as suggested here, I've also
used cl-http as a pure daemon (writing stdout to a log file),
with a REPL tcp server listening on localhost for interaction.
--
(espen)
From: Marcus Breiing
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <tjj3ja3cbsl65@breiing.com>
* Espen Vestre
> YMMV, in addition to using screen etc. as suggested here, I've also
> used cl-http as a pure daemon (writing stdout to a log file), with a
> REPL tcp server listening on localhost for interaction.
I prefer that kind of setup with cmucl. If something goes wrong,
cmucl loves to just hang there, waiting patiently inside an
interactive debugger for some human contact. Having it talk to a
logfile instead of a pty seems like the most robust way of curing
that.
However, I don't like to use a TCP socket for interaction, because
that would tear down the wall between unix-level users, which,
security-wise, could make me lose sleep. I've recently posted
something about using Slime with unix-domain sockets to the
slime-devel list. Maybe support for non-tcp connections makes it into
the official version some day.
Marcus
--
Marcus Breiing
http://www.breiing.com/usenet/tjj3ja3cbsl65
(Use link after email address has expired)
From: Espen Vestre
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <IZEDd.3318$IW4.72320@news2.e.nsc.no>
Marcus Breiing <···············@breiing.com> writes:
> However, I don't like to use a TCP socket for interaction, because
> that would tear down the wall between unix-level users, which,
> security-wise, could make me lose sleep.
Sure. I've used two different amendments for that. The first solution
was to simply use a password file for the repl daemon. Now I use a
different approach: The daemon generates a cookie (large integer)
every now and then and writes this to file that's only readable by
its owner. A little shell script connects to the daemon (which listens
to localhost only) and feeds it its cookie.
--
(espen)
From: Rob Warnock
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <_bqdnTA6mPem_kLcRVn-og@speakeasy.net>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
+---------------
| Marcus Breiing <···············@breiing.com> writes:
| > However, I don't like to use a TCP socket for interaction, because
| > that would tear down the wall between unix-level users, which,
| > security-wise, could make me lose sleep.
|
| Sure. I've used two different amendments for that. The first solution
| was to simply use a password file for the repl daemon. Now I use a
| different approach: The daemon generates a cookie (large integer)
| every now and then and writes this to file that's only readable by
| its owner. A little shell script connects to the daemon (which listens
| to localhost only) and feeds it its cookie.
+---------------
A simpler/related approach is to use "detachtty" and put its
Unix-domain socket underneath a directory only you can access.
Then only you can "attachtty" to it...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Wade Humeniuk
Subject: Re: starting a long-lived Lisp process from a short-lived connection
Date:
Message-ID: <BuwDd.61980$KO5.37450@clgrps13>
·········@hotmail.com wrote:
> I'd like to start a web server (cl-http) process from a remote client
> so that it keeps running after the client connection is closed.
>
> Would using cron to start the lisp process be a viable way of doing
> this? Right now I don't see a way of anticipating and handling all the
> possible errors...
>
You have not said what operating system. On FreeBSD I use daemon (see
FreeBSD man pages).
At the man page search page
http://www.freebsd.org/cgi/man.cgi
enter keyword daemon
Wade
Wade Humeniuk wrote:
> ·········@hotmail.com wrote:
> > I'd like to start a web server (cl-http) process from a remote
client
> > so that it keeps running after the client connection is closed.
> >
> > Would using cron to start the lisp process be a viable way of doing
> > this? Right now I don't see a way of anticipating and handling all
the
> > possible errors...
> >
>
> You have not said what operating system.
Sorry- it's Solaris 8.
> On FreeBSD I use daemon (see
> FreeBSD man pages).
>
> At the man page search page
>
> http://www.freebsd.org/cgi/man.cgi
>
> enter keyword daemon
>
> Wade