[ naviserver-Feature Requests-1171843 ] nsd -c: start a REPL

[SourceForge.net <no...@so...>]

Feature Requests item #1171843, was opened at 2005-03-28 06:43
Message generated for change (Comment added) made by sdeasey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1171843&group_id=130646

>Category: C-API
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stephen Deasey (sdeasey)
Assigned to: Stephen Deasey (sdeasey)
Summary: nsd -c: start a REPL

Initial Comment:

Here's a patch which adds a new startup mode to the nsd
binary: -c command mode.  When selected, after the
server has started rather than eternaly wait for
signals it runs a Tcl shell and waits for commands.

The nice thing about this is that all the server
commands are available, which is not the case if you
simply load libnsd.so.

The main goal is testing.  I've done some cleanup and
you can now type 'make test' in the top level
directory.  'make runtest' will drop you into an
interactive shell.

It could do with some improvements: 'exit' should
probably trigger an orderly shutdown, and signals
aren't handled.

Unfortunately ns_geturl is spectacularly useless,
simply fetching the bytes of a file directly from the
file system.  Is this useful?  I would have expected it
to pass through registered procs etc.

I'm thinking maybe the way to go is an nstest module
which adds some extra commands to dummy up a connection
and run the registered proc.  It would be possible I
guess to also create nstestdb to create a dummy db
driver, and so on...


Feedback appreciated.



----------------------------------------------------------------------

>Comment By: Stephen Deasey (sdeasey)
Date: 2005-04-03 19:00

Message:
Logged In: YES 
user_id=87254


I've commited this to HEAD.  The following are now available:

make test
  run the test suite

make runtest
  start a server shell for interactive testing

make gdb
  run test suite under gdb, pausing at gdb prompt so
  break points can be added


----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-04-01 22:03

Message:
Logged In: YES 
user_id=184124

that could work with non multithreaded programs, with
threads, you never know which thread caused the segv

----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-04-01 19:14

Message:
Logged In: YES 
user_id=87254


Is this a core file size thing?  Maybe if you up the ulimit
you'll get the whole memory dump?

I have seen some setups where when the program crashes it
automatically calls gdb.  There's this in my postfix config
file:

debugger_command =
        PATH=/bin:/usr/bin:/usr/local/bin; export PATH;
(echo cont;
        echo where) | gdb $daemon_directory/$process_name
$process_id 2>&1
        >$config_directory/$process_name.$process_id.log &
sleep 5

Maybe you could trigger something like this from a segv,
save some typing?


----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-04-01 15:28

Message:
Logged In: YES 
user_id=184124

Also, i have a trick i've been using for a long time:

In debug mode i install SEGV handler and sleep foreever, so
i can attach to the process with gdb and check why it
crashed. The good thing about this, server it is still
running and all memory is avalable, in core dumps sometimes
access is limited. It could be special comman line switch
for this handler.

static void
Segv(int sig)
{
    Ns_Log(Error,"ns: SIGSEGV received %d",getpid());
    while(1) sleep(1);
}


----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-04-01 07:07

Message:
Logged In: YES 
user_id=184124

This patch

----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-03-31 21:22

Message:
Logged In: YES 
user_id=87254


What's ok, this patch or using socat?



----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-03-31 20:29

Message:
Logged In: YES 
user_id=184124

For tests it is okay

----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-03-31 20:10

Message:
Logged In: YES 
user_id=87254


It runs the full server, scheduled proc threads, conn
threads, the lot!  The -c option basically tells the server
not to fork into the background and to start reading
commands on stdin.

socat look neat, but it's not a standard program.  I think
it's very important that 'make test' Just Works.  If it's at
all difficult test won't be written or run.

I'm open to other options though.


----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-03-28 09:38

Message:
Logged In: YES 
user_id=184124

I usually use nscp & socat combination to test the server,
in this mode it runs as it should and all commands are
tested using the same environment as it will be in the
production.
In your mode, server is used like shared library, to test
commands interactively only, you still need to run the
server to test background procs/callbacks.
Is it possible to run server in foreground (-f) and spawn
Tcl shell at the same time. In this case, you have the
server and nscp-like shell at the same time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1171843&group_id=130646