[Bese-devel] Re: Load a custom ucwctl.conf

[Nathan Bird]

Side note: Does stop.lisp still exist? Is it supposed to, browsing the
darcsweb version of ucw_dev, the file is gone from ucw_dev/etc, but ucwctl
is still making sure one exists somewhere. (I commented that out for the
second). The patch comments of late seem to be leaning towards removing it?

>The first problem with the default /var is that a normal user cannot
>create files/folders in it, so I think we need to default to $HOME/var
>for a normal user when $VARROOT is empty (already present in the
>attached patch).  In case an user (root or not) want to start two
>instances, he needs to specify the necessary variables.
>
>The other problem is the one you pointed out: with the default values
>(and with the commands ucwctl uses), if you start two processes
>they'll try to share the same socket (impossible) and log files
>(undesirable).  So, we need to modify how we create sockets, pid and
>log files.
>
>IMHO the better solution will be to check if the socket is present
>before parsing the command parameter (so, after having parsed all the
>variables).  If it's present, the script will exit with an error,
>otherwise it'll continue.  Waiting for comments...  :-)
>
>Another option we can add is the ability to use ucwctl without
>detachtty, something like -d or --no-detachtty: it starts UCW via
>cl-launch, but on the same terminal you are.  Could it be useful?
>

I like the idea of --no-detachtty, but running a second command for attach
isn't too bad in the meantime.

In my global ucwctl.conf I am currently specifying only the lisp="SBCL" and
the global start.lisp. I then try to launch it with ./ucwctl -c
../etc/conf.lisp start. This tries to get everything going. It looks like it
is correctly using the $HOME/var.

Aside from that observation it is hard to test out the rest of the
combinations because I still have the same (similar? Not sure) other
problems...

When I try to run it with cl-launch it seems to get as far as trying to
start the backend before complaining that trivial-sockets:open-server is
undefined[0]. But I then can't inspect anymore because of
--disable-debugger. I've tried removing all reference to
"--disable-debugger" in cl-launch that I could find, but apparently that
wasn't enough :-(

For reference, from ucw_dev/etc/, "CONFIGFILE=conf.lisp VARROOT=~ sbcl
--load start.lisp" does work just fine.

As far as I can tell cl-launch is doing its damnedest to mess up every
assumption I have ever made about how to startup lisp :-). <Nathan repeats
"With broken assumptions comes learning" ten times>.


[0]: Asdf didn't complain that it couldn't find that package, so I don't
think that is the problem. It only has a problem when it tries to call the
function:
0:33 UCW-LOGGER/+INFO+: Starting up standard server #<STANDARD-SERVER
MULTITHREAD-HTTPD-BACKEND 2 {B7981A9}>.
unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread"
{A68D4A9}>:
  Error during processing of --eval option
"(progn(set-dispatch-macro-character #\\# #\\! #'(lambda(stream char
arg)(declare(ignore char arg))(values (read-line stream))))(load
\"/usr/bin/cl-launch\" :verbose nil :print nil)
(funcall(intern(string :run):cl-launch) :init \"(load (pop
cl-launch:*arguments*))\" :quit nil))":

  The function TRIVIAL-SOCKETS:OPEN-SERVER is undefined.


I'm pretty sure that there is only one copy of trivial-sockets on the
system. It is linked into sbcl/site-systems.

I got homework that isn't getting done, I need to go procrastinate more
directly on that. I'll try again tomorrow.

Nathan